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1  Introduction 


The  goal  of  this  project  was  the  development  of  formal  methods  for  the  specifi¬ 
cation  and  verification  of  concurrent  programs  to  help  avoid  software  errors  in 
concurrent  systems.  This  involved  research  in  three  areas: 

•  Specification. 

•  Verification.  v.  • 

» 

•  Semantics. 

We  feel  that  previous  work  provides  an  adequate  formal  foundation  for  verifica¬ 
tion  [5,6,7],  so  we  have  concentrated  on  specification  and  semantics.  Our  work 
in  these  two  areas  is  summarized  in  the  following  two  sections. 

2  Specification 

A  formal  specification  should  describe  precisely  what  it  means  for  an  implemen¬ 
tation  to  be  correct.  This  requires  a  precise  definition  of  what  it  means  for  a 
program  to  satisfy  a  specification.  Without  such  a  definition,  a  formal  specifi¬ 
cation  is  at  best  incomplete,  and  may  be  little  better  than  an  informal  one  for 
producing  correct  software. 

The  precise  connection  between  a  specification  and  its  implementation  is 
subtle.  The  specification  is  generally  given  in  terms  of  large,  high-level  opera¬ 
tions,  which  the  program  implements  as  a  series  of  lower-level  operations.  Most 
research  on  specification  has  ignored  the  question  of  what  it  means  for  a  series 
of  low-level  operations  to  implement  a  single  high-level  one.  As  a  result,  the 
specifications  written  with  most  formalisms  are  incomplete.  The  specification 
of  a  FIFO  queue  is  one  of  the  standard  toy  examples.  However,  in  very  few  of 
the  specifications  can  one  decide  if  the  specification  is  supposed  to  be  satisfied 
by  writing  a  program  or  building  a  piece  of  hardware.  It  can  be  argued  that  this 
is  a  lower-level  question  that  these  specification  are  not  attempting  to  address. 
However,  it  is  disturbing  that  the  question  of  how  this  could  be  specified  is  not 
addressed.  A  specification  that  does  not  specify  whether  an  implementation 
should  consist  of  a  program  or  a  piece  of  hardware  cannot  help  the  designer 
avoid  the  more  subtle  interface  problems  that  plague  real  systems. 

The  reason  for  the  incompleteness  is  that  a  specification  of  a  module  in  a 
concurrent  system  must  have  two  components:  an  internal  part  that  describes 
the  invisible,  internal  behavior,  and  an  interface  part  that  specifies  precisely 
how  the  module  interacts  with  its  environment.  While  the  internal  part  is 
independent  of  the  implementation  details,  the  interface  specification  must  be 
given  in  terms  of  implementation-level  concepts.  Most  specification  methods 
consider  only  the  internal  specification  and  ignore  the  interface  specification.  It 


is  the  interface  specification  that  determines  if  a  queue  is  implemented  in  code 
or  silicon. 

Ignoring  the  interface  specification  can  lead  to  misleading  specifications — 
ones  that  are  either  meaningless  or  incapable  of  being  implemented.  This  is 
indicated  by  the  surprising  result  that  no  current  method  seems  capable  of 
providing  a  formal  specification  of  first-come-first-served  priority.  Thus,  for 
example,  the  informal  requirement  in  the  Ada  programming  language  that  re¬ 
quests  for  interprocess  communication  obey  such  priority  seems  incapable  of 
being  made  formal. 

A  detailed  discussion  of  the  problem  of  the  formal  connection  between  a  spec¬ 
ification  and  its  implementation  is  given  in  [3],  which  is  attached  as  Appendix  A 
of  this  report.  This  work  also  explains  our  assertion  that  first-come-first-served 
priority  cannot  be  adequately  specified  by  current  methods. 

3  Semantics 

Just  as  a  specification  method  should  define  what  it  means  for  a  program  to 
implement  a  specification,  we  believe  that  a  formal  semantics  should  define  what 
it  means  for  the  “machine-language”  program  generated  by  a  compiler  to  be  a 
correct  implementation  of  a  program.  Thus,  we  regard  a  program  formally  to 
be  a  specification  of  a  lower-level,  compiled  version.  Our  work  on  semantics 
has  thus  been  driven  by  the  need  to  establish  a  formal  connection  between 
the  programming  language’s  operations  and  the  lower-level  machine-language 
operations  with  which  they  are  implemented. 

We  have  developed  a  general  method  for  specifying  the  semantics  of  concur¬ 
rent  programming  languages.  Our  approach  of  viewing  a  program  as  a  spec¬ 
ification  of  its  compiled  version  led  to  a  semantics  in  which  the  meaning  of  a 
program  is  a  temporal  logic  specification  similar  to  the  ones  described  in  [2], 
Our  method  can  be  used  to  define  a  formal  semantics  for  all  concurrent  program¬ 
ming  constructs  that  we  have  been  able  to  think  of.  The  method  is  described 
in  jl],  which  is  included  as  Appendix  B  of  this  report. 

Since  the  semantics  of  a  language  consists  not  of  a  single  specification  but 
of  an  algorithm  for  generating  a  specification  for  every  program,  several  logical 
concepts  not  present  in  [2j  had  to  be  introduced.  One  of  these  concepts  was  a 
new  way  of  reasoning  about  aliasing. 

An  important  goal  of  our  method  was  compoiitionality — obtaining  the  mean¬ 
ing  of  a  program  from  the  meaning  of  its  components.  Combining  components 
of  a  program  leads  to  implicit  aliasing;  for  example,  when  two  processes  are 
“hooked  up”  to  a  unidirectional  communication  channel,  there  is  an  implicit 
aliasing  between  the  sender’s  output  buffer  and  the  receiver’s  input  buffer.  Such 
aliasing  is  of  a  more  general  nature  than  the  identification  of  program  variables 
usually  understood  as  aliasing.  To  handle  it,  we  (in  collaboration  with  Fred 
Schneider)  developed  a  method  of  reasoning  about  invariant  relations — ordinary 
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aliasing  being  an  invariant  relation  of  equality  between  the  values  of  two  vari¬ 
ables.  This  method  provides  an  elegant  new  method  for  handling  aliasing  and 
typing  relations  in  ordinary  sequential  programs  that  is  described  in  [4],  which 
is  included  as  Appendix  C  of  this  report. 
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Abstract 

The  formal  correspondence  between  an  implementation 
and  its  specification  is  examined.  It  is  shown  that  exist¬ 
ing  specifications  that  claim  to  describe  priority  are  either 
vacuous  or  else  too  restrictive  to  be  implemented  in  some 
reasonable  situations.  This  is  illustrated  with  a  precisely 
formulated  problem  of  specifying  a  first-come-first-served 
mutual  exclusion  algorithm,  which  it  is  claimed  cannot  be 
solved  by  existing  methods. 


pri-or'i-ty  (prl-Sr'f  tl),  n. ;  pi.  -TIES(-tfz).  3.  Order  of 
preference  based  on  urgency,  importance,  or  merit.  [1] 

1  Introduction 

Specification  and  Implementation 

A  formal  specification  method  should  reduce  the  question 
of  whether  a  program  satisfies  its  specification  to  a  pre¬ 
cisely  formulated  mathematical  problem.  This  reduction  is 
what  distinguishes  a  formal  method  from  an  informal  one. 
Most  researchers  developing  specification  formalisms  have 
concentrated  upon  the  formal  semantics  of  the  specifica¬ 
tion  language,  apparently  believing  that  such  a  semantics, 
together  with  a  formal  semantics  for  the  programming  lan¬ 
guage.  provides  the  necessary  reduction.  However,  formal 
semantics  for  the  specification  and  programming  languages 

'This  work  was  supported  in  part  by  the  National  Science  Foundation 
under  grant  number  MCS-8 101159,  and  the  Army  Research  Office 
under  grant  number  DA  AG29-83-K-01 19. 


are  not  enough;  one  must  also  define  the  correspondence 
between  the  two  semantics. 

As  a  trivial  example,  consider  a  program  to  compute  the 
square  of  an  integer.  The  specification  might  be  given  in 
terms  of  mathematical  integers,  while  the  program’s  seman¬ 
tics  might  be  defined  in  terms  of  bit  strings.  To  determine 
if  the  program  meets  its  specification,  we  must  define  the 
correspondence  between  the  implementation-level  semantic 
concept  of  bit  string  and  the  specification-level  concept  of 
integer.  Although  this  is  easy  to  do,  it  is  important  that  it 
be  done;  a  program  that  expects  input  values  to  be  in  two's- 
complement  representation  may  produce  an  incorrect  an¬ 
swer  when  given  an  input  value  encoded  in  sign-magnitude 
representation. 

For  sequential  programs,  specified  in  terms  of  input  and 
output  values,  the  correspondence  between  implementation 
and  specification  concepts  is,  in  principle,  simple:  it  is  just 
a  mapping  between  two  domains  of  values.  However,  this 
is  not  the  case  for  concurrent  programs,  where  the  specifi¬ 
cation  involves  the  program’s  behavior.  The  granularity  of 
operations  can  be  very  different  at  the  two  levels;  an  atomic 
operation  at  the  specification  level  may  correspond  to  a 
large  number  of  atomic  program  operations.  The  formal 
correspondence  between  the  two  semantic  levels  requires 
careful  examination.  In  this  paper,  I  consider  the  implica¬ 
tions  of  this  correspondence  for  the  particular  problem  of 
specifying  priority. 

Priority 

In  concurrent  systems,  priority  denotes  the  order  of  pref¬ 
erence  in  which  processes  obtain  service.  It  may  be  based 
upon  the  nature  of  the  service  being  requested,  the  im¬ 
portance  of  the  requesting  process,  or  the  order  in  which 
requests  are  issued.  All  popular  methods  for  specifying 
concurrent  systems  allow  one  to  write  simple  specifications 
that  appear  to  describe  priority.  However,  I  will  show  that, 
depending  upon  how  they  are  interpreted,  these  specifica¬ 
tions  are  either  too  restrictive  to  be  implementable  in  all 
situations  or  else  they  are  vacuous,  being  satisfied  by  any 
program. 

I  will  concentrate  upon  a  particular  example  of  prior¬ 
ity:  first-come-first-served  (FCFS).  There  is  nothing  special 


about  FCFS — the  same  problem  arises  in  specifying  other 
types  of  priority;  FCFS  just  provides  a  simple,  well-studied 
case.  It  is  also  an  important  case;  the  Ada  language  re¬ 
quires  an  FCFS  queuing  discipline  in  the  implementation 
of  the  rendezvous  mechanism,  and  problems  in  formally 
specifying  this  requirement  may  be  of  some  interest  to  the 
Ada  community. 

My  claim  that  current  methods  cannot  specify  priority 
is  a  controversial  one,  and  provokes  arguments  when  pre¬ 
sented  to  computer  scientists.  I  have  therefore  formulated 
a  challenge  to  those  who  feel  that  they  know  how  to  specify 
priority:  the  specification  of  a  precisely-defined  FCFS  mu¬ 
tual  exclusion  algorithm.  I  believe  that  anyone  claiming  to 
have  a  general  method  for  specifying  concurrent  programs 
should  be  able  to  write  the  required  specification.  By  a 
■‘general”  method,  I  mean  one  that  permits  implementa¬ 
tions  in  a  reasonably  broad  class  of  programming  languages. 
Given  some  particular  programming  language  having  an 
FCFS  synchronization  primitive,  it  is  easy  to  specify  FCFS 
priority  for  programs  written  in  that  language  by  requiring 
the  implementation  to  use  the  FCFS  primitive.  To  prevent 
this  kind  of  “cheating”,  the  challenge  specifies  two  simple 
programming  languages  that  must  be  handled. 

The  challenge  is  presented  first,  before  any  explanation 
of  what  makes  specifying  priority  difficult.  I  urge  the  reader 
to  study  it  and  decide  if  it  is  reasonable  before  reading  the 
rest  of  the  paper.  There  are  no  tricks  in  the  challenge; 
the  problem  that  arises  in  trying  to  specify  priority  is  a 
fundamental  one.  For  a  cry  of  “foul”  to  be  taken  seriously, 
it  should  be  issued  on  the  basis  of  the  challenge  alone,  not 
on  the  ensuing  discussion. 

2  The  Challenge 

Let  Blaise  be  a  simple  concurrent  programming  language 
with  an  atomic  assignment  statement,  concatenation  (  ;  ), 
if  and  while  statements  with  atomic  tests,  a  cobegin,  and 
integer  and  boolean  shared  variables,  but  with  no  explicit 
synchronization  or  communication  commands.  The  cobe¬ 
gin  is  assumed  to  be  fair,  meaning  that  a  nonterminated 
process  will  eventually  execute  its  next  atomic  operation, 
but  no  bound  is  assumed  on  the  relative  execution  speeds  of 
the  different  processes.  All  r'assical  shared-variable  multi¬ 
process  algorithms  can  easily  be  written  as  Blaise  programs. 

Let  the  language  Tony  be  the  same  as  Blaise  except  with 
no  shared  variables,  instead  using  CSP-style  communica¬ 
tion  primitives.  Moreover,  assume  an  appropriate  fairness 
requirement  on  communication  so  that  a  Blaise  program 
can  be  simulated  in  the  obvious  way  by  a  Tony  program 
in  which  shared  variables  are  replaced  by  extra  processes.1 
Reading  the  value  of  a  Blaise  shared  variable  is  simulated 
by  a  “?”  operation  in  the  Tony  program,  and  writing  its 
value  is  simulated  by  a 

Mutual  exclusion  algorithms  that  can  be  written  in  Blaise 

'Without  tome  fairness  constraint  on  communication,  a  Tony  program 
cannot  guarantee  the  fairness  condition  for  a  Blaise  process  that  ac¬ 
cesses  a  shared  variable. 


have  been  studied  for  years  [3],  and  there  is  a  general  agree¬ 
ment  that  certain  algorithms  are  FCFS  and  others  are  not. 
It  is  less  clear  what  it  means  for  a  Tony  program  to  be 
FCFS,  but  it  is  easy  to  write  Tony  programs  that  are  obvi¬ 
ously  not  FCFS — for  example,  an  algorithm  with  a  central 
scheduling  process  that  does  not  always  grant  requests  in 
the  order  it  receives  them. 

The  challenge  is  to  specify  program  statements  entry 
and  exitp,  for  p  =  1,. . . ,  17,  such  that  if  the  statement 

entryp\  critical  section;  exitp  (1) 

is  embedded  in  the  sequential  process  trp,  then 

cobegin  itt  || . . .  ||  tr,7  coend 

is  an  FCFS  mutual  exclusion  algorithm  in  which  irp  requests 
entry  to  its  critical  section  by  initiating  the  execution  of  ( 1). 
(There  may  also  be  declarations  of  the  shared  variables  in 
a  Blaise  program  and  extra  processes  in  a  Tony  program.) 
The  specification,  and  the  specification  method,  must  have 
the  following  properties. 

1.  For  any  Blaise  or  Tony  implementations  of  the  entry p 
and  exitp  statements,  the  method  defines  a  mathemat¬ 
ical  formula  C  and  a  formal  system  L  such  that  the 
implementation  satisfies  the  specification  if  and  only  if 
C  is  a  valid  formula  of  L. 

[This  is  a  precise  statement  of  the  requirement  that  a 
formal  method  reduce  the  question  of  whether  a  partic¬ 
ular  program  satisfies  the  specification  to  a  well-defined 
mathematical  problem.] 

2.  (a)  Any  Blaise  implementation  that  is  generally  re¬ 
garded  to  be  an  FCFS  mutual  exclusion  algorithm 
must  satisfy  the  specification. 

(b)  A  Tony  simulation  of  such  a  Blaise  program  must 
also  satisfy  the  specification. 

3.  Any  Blaise  or  Tony  program  that  is  generally  regarded 
not  to  be  an  FCFS  mutual  exclusion  algorithm  must 
not  satisfy  the  specification. 

I  will  attempt  to  answer  all  serious  responses  to  this  chal¬ 
lenge.  To  meet  the  challenge,  you  must  provide  the  spec¬ 
ification  and  indicate  how  one  constructs  the  C  and  L  of 
condition  1  for  any  Blaise  or  Tony  program.  I  will  then 
attempt  to  present  one  or  more  programs  that  violate  con¬ 
dition  2  o-  3,  in  which  case  you  must  show  that  these  condi¬ 
tions  are  not  violated.  The  construction  of  C  and  L  and  the 
refutation  of  my  counterexamples  need  not  be  given  in  full 
mathematical  detail,  but  they  must  be  rigorous  enough  to 
convince  a  competent  computer  scientist  that  a  completely 
formal  exposition  is,  in  principle,  possible. 


3  What’s  So  Hard  About  The 
Challenge? 

Why  Current  Methods  Don’t  Work 

Let  us  now  consider  how  one  might  specify  the  FCFS 
condition  of  the  challenge.  Intuitively,  FCFS  means  that 
requests  to  enter  the  critical  section  are  serviced  in  the 
order  in  which  they  are  issued.  To  specify  this  more  pre¬ 
cisely,  one  must  recognize  two  kinds  of  operations — a  re¬ 
quest  operation  and  a  critical. section  operation.  To  each 
critical. section  operation  there  corresponds  a  request  oper¬ 
ation,  issued  before  it  by  the  same  process.  We  identify  op¬ 
erations  by  subscripts,  letting  request t  and  critical.sectioni 
denote  corresponding  operations.  The  FCFS  priority  con¬ 
dition  is  usually  expressed  as  follows: 

(*)  For  any  distinct  operations  critical.sectioni  and 
eritical.sectiorij,  if  request ,•  precedes  request j  then 
critical.sectioni  must  precede  critical.sectioni. 

The  operations  request,-  and  request  j  need  not  be  atomic 
actions.  The  condition  “request,  precedes  request  *  means 
that  request ,  finishes  before  request  j  begins.  If  these  opera¬ 
tions  are  nonatomi c,  then  they  can  be  concurrent,  meaning 
that  neither  precedes  the  other.  In  this  case,  condition  (*) 
does  not  specify  the  order  of  the  operations  critical.sectioni 
and  critical  .section  j.  Allowing  the  request  operations  to  be 
nonatomic  means  that  the  order  of  service  does  not  mat¬ 
ter  (is  not  specified)  if  the  requests  are  issued  “too  close 
together" . 

All  the  formal  specification  methods  I  know  of— including 
(41.  (51,  (8],  (II),  [131,  [Hi,  [15],  [16],  (17),  and  [l^-specify 
FCFS  with  condition  (*),  although  the  formal  expression 
of  this  condition  differs  with  the  different  methods.  These 
differences  are  irrelevant  to  the  fundamental  problem  with 
condition  (*). 

To  verify  that  a  Blaise  program  satisfies  (*),  one  must 
state  what  Blaise  operations  correspond  to  the  operations 
reqvesti  and  critical.sectioni.  The  critical.sectioni  opera¬ 
tion  clearly  corresponds  to  an  execution  of  the  critical  sec¬ 
tion,  but  what  about  the  request,-  operation?  Let  «nf«r< 
denote  the  operation  by  which  a  process  initiates  execu¬ 
tion  of  its  entry,  statement,  so  enter i  is  an  execution  of 
the  atomic  action  that  puts  the  process’s  control  at  the  be¬ 
ginning  of  that  statement — in  other  words,  the  last  atomic 
action  before  the  process  executes  entry,.  What  is  the  re¬ 
lation  between  the  atomic  action  enter,-  and  the  operation 
request ,?  There  are  two  possibilities: 

1.  enter i  equals  request making  request ;  an  atomic  ac¬ 
tion. 

2.  enter,-  is  the  first  action  of  the  nonatomic  operation 
request ,. 

I  will  examine  each  of  them  in  turn. 

In  the  first  case,  where  request;  is  the  atomic  action 
putting  the  process  at  its  entry  statement,  condition  (*) 


cannot  be  satisfied  by  any  implementation.  There  is  no 
way  for  two  entry  statements  to  determine  in  which  order 
they  were  entered.  Hence,  no  algorithm  can  ensure  that 
the  critical-section  operations  occur  in  the  order  required 
by  condition  (*). 

It  might  seem  unfair  not  to  make  en/er,  part  of  the  the 
entry ,  statement,  and  one  might  define  enter ;  to  be  the 
first  atomic  action  of  entry,.  However,  this  does  not  solve 
the  problem  because  an  atomic  action  of  a  Blaise  program 
can  either  read  or  write  a  shared  variable,  but  cannot  do 
both.  Thus,  if  request,-  is  the  atomic  action  enter,-,  then 
the  request,-  operation  cannot  both  announce  the  process’s 
desire  to  enter  its  critical  section  and  check  for  the  presence 
of  other  processes  waiting  to  enter  their  critical  sections.5 
If  the  two  operations  requesti  and  request ;-  occur  too  close 
together,  no  algorithm  can  determine  which  one  happened 
first,  even  though  the  semantics  of  Blaise  specifies  that  they 
occur  in  some  definite  order.  Hence,  a  Blaise  implementa¬ 
tion  still  cannot  satisfy  condition  (*). 

Now  consider  the  second  case.  If  enter,-  is  only  the  first 
action  of  the  request;  operation,  when  does  the  operation 
end?  This  question  is  not  answered  by  the  specification. 
Since  the  end  of  the  request,-  operation  happens  while  ex¬ 
ecuting  the  entry,  statement,  which  is  provided  by  imple¬ 
mentor,  he  must  be  the  one  who  decides  where  the  request ( 
operation  ends.  In  order  to  prove  that  his  implementa¬ 
tion  meets  condition  (*),  the  implementor  may  define  the 
end  of  the  request,-  operation  to  be  anywhere  he  wishes.  In 
particular,  he  can  define  requesti  to  include  the  entire  ex¬ 
ecution  of  the  statement  entry,.  With  this  definition,  any 
algorithm  that  enforces  mutual  exclusion  of  critical-section 
operations  trivially  satisfies  condition  (*).  Thus,  in  this 
case,  the  condition  is  vacuous. 

What  Does  Priority  Really  Mean? 

What  do  we  mean  when  we  say  that  something  is  an 
FCFS  algorithm?  FCFS  was  defined  in  |10]  by  condi¬ 
tion  (*),  under  the  interpretation  in  which  requesti  >s  a 
nonatomic  operation,  with  the  following  additional  con¬ 
straint: 

(t)  The  requestf  operation  does  not  involve  any  waiting  for 
other  processes. 

To  prove  that  his  program  is  FCFS,  the  implementor  is  free 
to  define  request;  any  way  he  likes  so  long  as  condition  (“) 
is  satisfied.  For  a  Blaise  program,  in  which  “busy  waiting" 
is  the  only  kind  of  waiting  possible,  (|)  is  satisfied  if  the 
execution  of  requesti  takes  a  bounded  number  of  program 
steps.’ 

There  is  no  obvious  way  to  define  absence  of  waiting 
for  a  Tony  program,  which  can  make  it  difficult  to  decide 

’This  appears  to  be  a  folk  theorem,  having  been  known  to  a  number 
of  people  but  never  published. 

’Note  that  this  does  not  mean  that  the  execution  take;  a  bounded 
length  of  time:  Blaise  does  not  guarantee  any  bound  oo  bow  long  a 
process  may  wait  before  executing  one  step. 


whether  or  not  a  Tony  program  is  an  FCFS  algorithm.  This 
is  the  reason  the  challenge  requires  that  a  Tony  simulation 
of  an  FCFS  Blaise  program  be  regarded  as  FCFS.  The  sim¬ 
ulation  can  be  viewed  as  a  “compiled  version"  of  the  Blaise 
program,  and  it  is  reasonable  to  expect  the  compiled  ver¬ 
sion  of  an  FCFS  program  also  to  be  an  FCFS  program. 

To  specify  FCFS,  one  needs  both  (*)  and  (|),  so  one  must 
be  able  to  define  what  waiting  means.  Moreover,  the  defini¬ 
tion  of  waiting  should  be  independent  of  the  programming 
language,  since  the  specification  of  the  reqvesti  operation 
should  not  depend  upon  how  en tryf  and  exitp  are  imple¬ 
mented.  For  example,  entry  and  exitp  might  call  subrou¬ 
tines  that  invoke  special-purpose  hardware  to  perform  the 
uecessary  synchronization. 

Specifying  other  kinds  of  priority  poses  exactly  the  same 
difficulty  as  specifying  FCFS.  Consider  the  classical  read¬ 
ers/writers  problem  with  writer  priority  [2].  In  this  prob¬ 
lem.  a  process  that  has  issued  a  request  to  write  has  prece¬ 
dence  over  a  reader  that  has  not  yet  begun  to  read.  Letting 
start,  rdi  denote  the  operation  of  starting  to  read,  this  is  ex¬ 
pressed  as  follow  s. 

(«')  For  any  operations  twite,-  and  ready,  if  request ,-  pre¬ 
cedes  start. rij  then  twite,-  must  precede  ready. 

Condition  (*')  has  the  same  trouble  as  condition  («).  If 
request ,  is  the  operation  enter;  that  begins  the  request,  then 
no  Blaise  program  can  meet  this  specification.  On  the  other 
hand,  if  the  implementor  is  allowed  to  define  the  endpoint 
of  this  operation,  then  condition  («')  is  vacuous  because 
requesti  can  be  defined  to  extend  until  the  beginning  of 
twite,. 

4  A  Closer  Look  at  Specification 

An  Informal  Look 

The  difficulty  in  specifying  priority  should  convince  the 
reader  that  we  need  to  examine  more  closely  what  it  means 
for  a  program  to  implement  a  specification.  To  write  a 
specification,  there  must  be  an  object  to  be  specified  and 
a  well-defined  interface  between  the  object  and  its  envi¬ 
ronment.  We  can  ask  for  a  specification  of  a  telephone 
exchange  because  we  know  both  the  object  to  be  speci¬ 
fied  (the  exchange)  and  its  interface  with  the  environment 
(the  wires  leading  to  the  telephones  on  the  exchange  and  to 
other  exchanges).  It  is  meaningless  to  ask  for  a  specifica¬ 
tion  of  the  solar  system  because  we  have  no  idea  what  the 
interface  is  between  the  solar  system  and  its  environment. 

I  will  call  the  object  being  specified  a  “module".  A  com¬ 
plete  specification  of  a  module  must  contain  all  the  infor¬ 
mation  needed  to  determine  if  a  particular  implementation 
is  correct,  where  correctness  means  that  the  module  in¬ 
teracts  properly  with  its  environment.  An  examination  of 
the  specifications  presented  to  illustrate  most  methods — 
for  example,  the  specification  of  a  queue  (bounded  buffer) 
in  (8).  [17],  or  [18] — reveals  that  they  are  incomplete.  From 
these  specifications,  one  cannot  tell  whether  the  operations 


are  initiated  by  calling  a  subroutine  or  by  raising  a  volt¬ 
age  on  a  wire.  A  program  and  a  piece  of  hardware  cannot 
both  interact  properly  with  the  same  environment.  Only 
in  [llj  is  the  interface  specified,  being  defined  as  a  simple 
subroutine-calling  mechanism,  but  there  was  no  explana¬ 
tion  of  why  this  implementation-level  detail  was  introduced 
into  a  paper  on  specification. 

A  complete  specification  must  have  two  parts:  a  spec¬ 
ification  of  the  module’s  interface  and  a  specification  of 
its  internal  behavior.  The  internal  behavior  can  be  spec¬ 
ified  in  terms  of  high-level  abstractions  like  queues  and 
write  operations.  However,  since  the  interface  determines 
whether  an  operation  is  initiated  by  calling  a  Pascal  sub¬ 
routine  named  put  or  by  raising  the  voltage  on  line  num¬ 
ber  7  to  4.5  ±  1  volts,  it  must  be  specified  in  terms  of 
implementation-level  concepts  like  subroutine  names  and 
voltages.  We  want  to  make  the  interface  specification  as 
small  as  possible,  specifying  as  much  as  we  can  in  terms 
of  the  internal  behavior,  which  can  be  described  with  nice, 
high-level  concepts;  but  the  interface  specification  is  neces¬ 
sary.  Most  specification  methods  ignore  the  interface  and 
consider  only  the  internal  behavior. 

The  implementor  should  have  complete  freedom  in  im¬ 
plementing  the  objects  and  operations  that  describe  the 
internal  behavior.  If  the  specification  contains  an  internal 
operation  that  puts  an  object  on  a  queue,  then  the  imple¬ 
mentor  can  define  that  operation  to  be  the  act  of  storing  an 
item  in  an  array,  of  adding  it  to  a  linked  list,  or  of  setting  the 
voltage  levels  on  the  wires  leading  to  some  special  device. 
On  the  other  hand,  the  interface  must  be  completely  spec¬ 
ified  at  the  implementation  level.  The  need  to  partition  a 
specification  into  an  interna]  part,  which  is  implementation- 
independent,  and  an  interface  specification,  which  depends 
upon  the  implementation,  was  recognized  in  [6],  and  is  em¬ 
bedded  in  the  Larch  system  [7]. 

In  the  challenge,  the  interface  is  described  by  requiring 
the  implementation  to  consist  of  Blaise  or  Tony  entry p  and 
ext tp  statements  that  are  used  in  a  particular  way.  Because 
I  ignored  the  problem  of  how  shared  variables  and  extra 
processes  are  declared,  I  could  pretend  that  the  Blaise  and 
Tony  implementations  had  the  same  interface  specification. 
In  a  more  formal  approach,  the  interface  would  have  to  be 
specified  somewhat  differently  for  the  two  languages. 

A  Formal  View 

As  described  in  condition  1  of  the  challenge,  a  formal 
method  for  proving  that  an  implementation  meets  its  spec¬ 
ification  must  convert  the  specification  and  its  implementa¬ 
tion  into  a  mathematical  formula  C  in  some  formal  system 
L  such  that  the  implementation  is  correct  if  and  only  if  C 
is  a  valid  formula  of  L.  I  now  give  a  very  vague,  high-level 
discussion  of  how  this  is  done. 

A  formal  specification  is  written  in  a  language  having  a 
formal  semantics,  which  means  that  the  specification  can 
be  translated  to  a  mathematical  object  S  in  some  formal 
system  S.  Similarly,  a  formal  semantics  for  the  implemen- 
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tation  language  describes  the  implementation  as  a  semantic 
object  7  in  a  formal  system  I.  To  be  able  to  speak  formally 
about  the  correctness  of  the  implementation,  there  must 
be  a  mapping  7  from  objects  in  the  system  S  to  objects 
in  the  system  I.  so  that  7(5)  is  an  object  of  I.  The  object 
7(5)  is  the  formal  representation  of  the  specification  in  the 
semantic  domain  of  the  implementation. 

The  formal  system  L  of  the  challenge  is  the  system  I, 
and  the  formula  X  that  expresses  the  correctness  of  the 
implementation  is  the  formula  of  I  that  means  “7  satisfies 
7(5)'.  Exactly  how  X  is  constructed  from  7(5)  and  7 
depends  upon  the  specification  method.  I  will  illustrate 
with  two  examples:  a  pure  axiomatic  approach  and  a  pure 
behavioral  approach. 

In  a  pure  axiomatic  approach,  an  axiomatic  semantics 
is  given  for  both  the  specification  and  the  implementation. 
An  axiomatic  semantics  defines  5  to  be  a  formula  of  the 
logical  system  S — the  conjunction  of  all  the  “axioms"  com¬ 
prising  the  specification — and  7  to  be  a  formula  of  I.  The 
mapping  7  is  a  function  from  the  formulas  of  S  to  those 
of  I.  For  example,  suppose  the  specification  is  in  terms  of 
the  value  of  a  queue  q,  which  is  implemented  with  an  array 
a.  To  talk  about  the  correctness  of  the  implementation, 
for  every  possible  value  a  of  the  array  a  we  must  know  the 
value  (J(a)  of  q  that  it  represents.4  For  any  formula  R  of 
S.  the  formula  7(J2)  of  I  is  obtained  by  substituting  Q( a) 
for  q  in  R.  Thus  T(R)  is  obtained  by  translating  the  state¬ 
ment  R,  which  is  an  assertion  about  the  specification-level 
object  q,  into  an  assertion  about  the  implementation-level 
object  a. 

In  this  approach,  X  is  the  formula  7  O  7(5).  In  other 
words,  the  implementation  is  correct  if  and  only  if  the  ax¬ 
ioms  comprising  the  semantics  of  the  implementation  imply 
the  axioms  of  the  specification,  after  the  latter  are  trans¬ 
lated  by  7  into  assertions  about  the  implementation.  This 
is  discussed  at  greater  length  in  [12]  for  one  particular  ax¬ 
iomatic  method. 

In  a  pure  behavioral  approach,  the  formal  semantics  of 
the  implementation  and  specification  are  sets  of  behaviors: 
S  is  the  set  of  all  behaviors  allowed  by  the  specification, 
7  is  the  set  of  all  behaviors  that  could  be  produced  by 
the  implementation,  and  S  and  I  are  formal  systems  for 
reasoning  about  sets  of  behaviors.  For  a  behavior  6  in  the 
specification  domain,  7(6)  is  the  corresponding  behavior 
in  the  implementation  domain.  In  the  mutual  exclusion 
example,  the  operation  cn/iraUaeclion,  is  a  single  action  in 
the  behavior  6:  it  corresponds  to  a  set  of  actions  in  7(6)  — 
namely,  the  set  of  all  the  Blaise  program  steps  in  a  single 
execution  of  the  critical  section. 

One  can  define  the  formula  X  to  be  7  C  7(5),  where 
7(5)  =  (7(6)  :  6  €  5).  In  other  words,  the  implementa¬ 
tion  is  correct  if  and  only  if  every  possible  behavior  of  the 
implementation  is  allowed  by  the  specification.  Some  spec¬ 
ification  methods  define  X  to  be  7  =7(5),  requiring  that 
the  implementation  be  able  to  produce  all  the  behaviors 

'Tbe  mapping  Q  may  be  partial,  since  Q{ a)  need  only  be  debned  for 
values  a  of  a  that  can  arise  during  the  program's  execution. 


described  by  the  specification. 

There  are  other  possibilities — for  example  an  axiomatic 
semantics  for  the  specification  and  a  behavioral  semantics 
for  the  implementation.  In  any  case,  the  definition  of  cor¬ 
rectness  of  the  implementation  involves  the  mapping  7.  For 
the  specification  of  FCFS,  the  mapping  7  is  what  deter¬ 
mines  which  operations  at  the  implementation  level  corre¬ 
spond  to  the  specification’s  request ,•  operation.  A  complete 
specification  must  include  not  only  5,  but  also  the  part  of 
7  that  determines  the  interface.  For  the  queue  example,  it 
is  this  part  of  7  that  specifies  whether  one  puts  an  element 
in  the  queue  by  calling  a  subroutine  or  raising  a  voltage 
level.  Correctness  means  that  there  exists  some  7.  part  of 
which  is  determined  by  the  specification,  such  that  7(5) 
satisfies  7.  The  implementor  is  free  to  define  the  rest  of 
7,  specifying  the  correspondence  between  the  implementa¬ 
tion  and  the  internal  part  of  the  specification  any  way  he 
wishes  in  order  to  prove  the  correctness  of  his  implementa¬ 
tion.  The  specification  places  no  constraint  on  any  part  of 
the  implementation  other  than  the  interface. 

5  Conclusion 

Having  described  the  difficulty  in  specifying  priority,  it 
would  be  nice  if  I  could  either  explain  how  it  can  be  done 
or  else  prove  that  it  is  impossible.  Unfortunately,  I  can 
do  neither.  I  believe  that  one  cannot  write  a  satisfactory 
general  specification  of  priority — one  that  works  for  a  vari¬ 
ety  of  implementation  domains.  The  difficulty  in  expressing 
priority  arises  from  the  requirement  that  the  request  opera¬ 
tion  should  involve  no  waiting  for  other  processes.  Waiting 
is  an  implementation-level  concept  that  I  feel  cannot  be 
expressed  in  a  general  way.  However,  this  conjecture,  like 
Church’s  thesis,  is  not  susceptible  to  formal  proof.  At  best, 
one  can  prove  only  that  some  particular  formalism  cannot 
express  priority. 

If  priority  is  not  expressible  by  current  formal  specifica¬ 
tion  techniques,  how  should  we  specify  concurrent  systems? 
Priority  is  general!)  regarded  to  be  a  fundamental  concept 
that  must  be  specified.  Must  we  add  new  primitives  to  ex¬ 
press  it7  My  tentative  answer  is  no.  I  believe  that  priority 
cannot  be  expressed  precisely  in  those  situations  when  it  is 
not  a  fundamental  property. 

Remember  that  condition  (*)  does  express  FCFS  priority 
if  the  request,  operation  is  interpreted  to  be  the  interface 
operation  enter,  The  atomicity  of  enter,  is  irrelevant;  what 
matters  is  that  request,  be  the  interface  operation  Priority 
is  a  basic  system  requirement  only  when  its  effect  is  directly 
visible  to  the  user,  which  is  the  case  only  when  the  request 
operation  is  externally  visible — that  is.  when  it  is  part  of 
the  interface  For  example,  suppose  we  want  transactions 
issued  by  certain  users  to  receive  higher  priority.  The  re¬ 
quest  operation  can  then  be  defined  as  the  entire  sequence 
of  actions  performed  by  the  user  in  issuing  the  request,  from 
the  first  keystroke  to  bis  notification  that  the  request  has 
been  accepted  by  the  system 

When  the  request  operation  is  not  externally  visible,  then 


must  also  do  the  same  for  other  language  constructs  besides  the  “ ; ” .  We 
will  see  that  there  is  a  standard  prescription  for  doing  this. 

The  axioms  in  M[5]  define  a  set  of  behaviors  for  5 — namely,  the  set  of  all 
behaviors  satisfying  the  temporal  logic  axioms  starting  in  states  that  satisfy 
the  axioms  for  the  starting  state.  Although  this  defines  a  set  of  behaviors  for 
every  statement,  it  is  different  from  a  semantics  in  which  M|[5j  is  taken  to 
be  a  set  of  behaviors  because  the  meaning  of  S  is  obtained  from  the  meaning 
of  its  components  by  “composing”  axioms,  not  by  composing  behaviors. 

2.3  Is  This  Fair? 

It  can  be  argued  that  the  semantics  of  a  programming  language  should  be 
defined  in  terms  of  constructive  operations  rather  than  with  axioms.  One 
should  give  a  procedure  for  constructing  the  set  of  behaviors  of  a  program 
rather  than  a  set  of  axioms  to  describe  it. 

While  a  purely  constructive  approach  would  be  nice,  it  seems  to  be 
impossible  to  deal  with  fairness  constructively.  Even  a  behavioral  semantics, 
which  looks  constructive,  really  includes  axioms  for  fairness.  A  behavioral 
semantics  defines  the  meaning  of  a  fair  cobegin  in  terms  of  fair  interleaving. 
The  definition  of  a  fair  interleaving  of  two  behaviors  goes  something  like  this: 

Construct  all  interleavings  and  then  throw  away  the  ones  that 
do  not  satisfy  the  fairness  condition. 

This  is  remarkably  similar  to  the  definition  of  the  set  of  behaviors  obtained 
from  a  set  of  actions  and  a  set  of  constraints,  which  can  be  expressed  as: 

Construct  all  behaviors  generated  by  the  set  of  actions  and  then 
throw  away  those  that  do  not  satisfy  the  constraints. 

One  might  argue  that  fair  interleaving  is  a  simple,  basic  concept,  and 
I  have  given  a  particularly  jaundiced  expression  of  it.  However,  there  are 
many  different  fairness  constraints  one  might  want  to  define,  each  of  which 
would  require  a  different  definition  of  fair  interleaving.  For  example,  consider 
two  coin-flipping  processes,  one  with  the  single  action  head  and  the  other 
with  two  actions:  tail  and  coin  lost.  The  first  process  generates  only  the 
sequence  of  all  heads,  the  second  process  generates  either  a  sequence  of  all 
tails  or  a  finite  string  of  tails  followed  by  a  sequence  of  coin  lost  actions. 
The  behaviors  resulting  from  executing  the  two  processes  concurrently  are 
defined  to  consist  of  all  possible  fair  sequences  of  heads  and  tails  plus  all 
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is  just  the  union  of  the  sets  of  possible  actions  of  jtj  and  nz-  Action  seman¬ 
tics  have  long  been  favorites  of  theoretical  computer  scientists  [15]  because 
they  lead  to  mathematically  well-behaved  formalisms.  Unfortunately,  these 
semantics  are  unsatisfactory  because  they  cannot  express  fairness.  Consider 
a  coin-flipping  program  with  two  possible  actions:  toss  a  head  and  toss  a 
tail.  It  can  be  viewed  as  the  parallel  composition  of  two  processes:  one  that 
generates  only  heads  and  the  other  that  generates  only  tails.  An  unfair  coin 
flipper  can  generate  any  infinite  sequence  of  heads  and  tails,  while  a  fair 
one  can  generate  only  sequences  containing  infinite  numbers  of  both  heads 
and  tails.  Both  the  fair  and  the  unfair  coin  flipper  have  the  same  set  of  ac¬ 
tions  (toss  a  head  and  toss  a  tail),  so  an  action  semantics  cannot  distinguish 
between  the  two. 

2.2.3  Action- Axiom  Semantics 

The  problem  of  fairness  is  solved  by  using  an  action-axiom  semantics  in 
which  the  meaning  of  a  statement  consists  of  a  set  of  actions  together  with 
a  set  of  temporal  logic  axioms  that  state  conditions  under  which  an  ac¬ 
tion  must  eventually  occur.  For  example,  the  fair  coin  flipper  requires  two 
axioms: 

•  At  any  time,  a  head  must  eventually  occur. 

•  At  any  time,  a  tail  must  eventually  occur. 

The  meaning  of 

assign  processor  to  5 

consists  of  the  meaning  of  S  plus  the  following  additional  axiom: 

•  If  5  is  being  executed — more  precisely,  if  control  is  in  S — then  an 
action  of  S  must  eventually  occur. 

We  are  thus  led  to  let  .MjS]  consist  of  a  set  of  actions,  a  set  of  temporal 
logic  axioms,  and  a  set  of  starting  states.  But  how  do  we  specify  the  actions? 
Instead  of  introducing  some  new  method  for  specifying  actions,  I  will  specify 
the  actions  as  well  as  the  fairness  properties  with  temporal  logic  axioms. 
Starting  states  will  be  specified  by  ordinary,  nontemporal  axioms. 

To  give  a  compositional  action  semantics,  we  must  define  the  axioms  of 
;V[Si;Ss]  in  terms  of  the  axioms  of  ,M|Si]  and  and,  of  course,  we 
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are  obtained  by  forming  interleavings  of  behaviors  from  Si  and  S2,  and  inter¬ 
leavings  are  rather  awkward  mathematically — especially  for  a  fair  cobegin, 
where  only  fair  interleavings  are  allowed. 

A  more  serious  problem  is  raised  by  the  language  construct 

assign  processor  to  S 

Intuitively,  this  statement  causes  the  compiler  to  assign  a  physical  (or  vir¬ 
tual)  processor  to  execute  S.  In  terms  of  behaviors,  it  means  that  any 
behavior  that  reaches  S  must  either  subsequently  reach  the  end  of  S  or  else 
include  an  infinite  number  of  actions  of  S.  In  other  words,  a  process  can¬ 
not  be  “starved”  while  it  is  executing  this  statement.  This  is  a  perfectly 
reasonable — and  compilable — statement.  It  can  be  used  to  construct  a  fair 
cobegin  from  an  unfair  one  as  follows: 

unfair  cobegin  assign  processor  to  Si  □ 

assign  processor  to  S2  coend 

More  complicated  uses  of  the  assign  processor  statement  are  also  possible. 
Considered  completely  by  themselves,  the  statements  S  and 

assign  processor  to  S 

have  the  same  sets  of  behaviors,  so  it  is  not  clear  how  one  could  apply  to 
the  assign  processor  statement  the  same  approach  used  above  to  define 
*[S,;S2  1. 

2.2.2  Action  Semantics 

Instead  of  defining  ,M|S|  to  be  the  set  of  behaviors  itself,  one  can  define  it 
to  be  something  that  can  be  used  to  construct  the  set  of  behaviors.  Since 
a  behavior  is  generated  by  a  sequence  of  actions  starting  in  some  state,  an 
obvious  approach  is  to  let  Xj5]  be  the  set  of  all  possible  actions  together 
with  the  set  of  all  possible  starting  states.  I  will  call  such  a  semantics  an 
action  semantics.  Given  an  action  semantics,  one  can  define  the  behaviors 
of  S  to  be  the  set  of  all  behaviors  that  can  be  obtained  from  these  actions 
starting  from  the  specified  starting  states. 

An  action  semantics  is  well-suited  to  expressing  parallelism,  since  the  set 
of  possible  actions  of 


the  o,  are  actions  of  that  process.  I  will  explain  later  exactly  what  states 
and  actions  are. 

The  semantics  that  I  am  aiming  for  is  an  axiomatic  one,  in  which  the 
meaning  of  a  program  is  a  set  of  axioms  in  a  formal  system.  An  important 
advantage  of  an  axiomatic  semantics  is  that  it  is  very  formal.  A  formal 
mathematical  system  is  one  in  ,/hich  reasoning  can  be  reduced  to  a  strict 
application  of  axioms  and  inference  rules.  Automated  deduction  systems 
can  usually  be  applied  only  to  a  formal  system.  A  semantics  in  which  Mj5j 
is  defined  to  be  a  set  of  sequences  is  really  semi-formal,  based  upon  the  in¬ 
formal  mathematical  concepts  of  sets  and  sequences.  Formalizing  it  requires 
formalizing  these  mathematical  concepts.  With  an  axiomatic  semantics,  this 
extra  step  is  unnecessary;  .Mj[S|  is  already  a  set  of  axioms  in  a  formal  system. 

The  problem  with  an  axiomatic  semantics  is  that  one  can  understand  the 
meaning  of  a  formal  logical  system  only  by  constructing  a  semantic  model 
for  it  in  terms  of  concepts  that  we  already  understand.  Having  constructed 
a  semantics  in  which  M  [5|  is  a  set  cfLaxioms  in  some  formal  system  is  only 
half  the  job;  we  also  have  to  define  a  semantics  for  the  formal  system  in 
terms  of  well-understood  mathematical  concepts. 

I  will  give  a  temporal  logic  semantics — one  in  which  the  axioms  are  tem¬ 
poral  logic  formulas.  I  will  rely  upon  the  usual  semantic  model  of  temporal 
logic,  described  later,  to  provide  a  basis  for  an  intuitive  understanding  of 
the  axioms. 

2.2  Different  Kinds  of  Semantics 
2.2.1  Behavioral  Semantics 

An  obvious  method  of  defining  a  semantics  for  concurrent  programs  is  to  let 
the  meaning  of  a  statement  be  its  set  of  possible  behaviors,  and  to  explicitly 
construct  the  behaviors  in  X|5|  from  the  behaviors  of  its  components.  For 
example,  the  set  of  behaviors  ,M|[Si ;  consists  of  all  infinite  behaviors  in 
;M[Si|  together  with  all  concatenations  of  finite  behaviors  in  Mj5i]  with 
behaviors  in  This  can  be  expressed  formally  by: 

;  5;1  =  {er  €  ;M|[5i]]  :  a  infinite} 

U  {<7 t  :  <7  €  M|[S|],  r  €  MfSs],  and  a  finite} 

I  will  call  such  a  semantics  a  behavioral  semantics. 

Behavioral  semantics  have  their  problems.  While  they  work  well  for 
sequential  programming  constructs,  they  are  less  satisfactory  for  concurrent 
languages.  The  behaviors  of 


to  reason  about  things  like  the  control  state  that  are  internal  to  the  pro¬ 
gram.  However,  years  of  experience  reasoning  about  concurrent  programs 
has  led  me  to  conclude  that  one  should  think  about  them  in  terms  of  the 
complete  state,  including  externally  invisible  compents  of  the  state.  I  will 
not  attempt  to  justify  this  conclusion  here,  and  will  simply  adopt  the  second 
approach,  defining  the  meaning  of  a  program  in  terms  of  complete  behaviors 
that  describe  the  internal  as  well  as  the  extemally-visible  effects  of  program 
operations. 

Having  decided  that  the  meaning  of  a  program  is  its  set  of  possible 
behaviors,  we  must  decide  what  a  behavior  is.  The  simplest  notion  of  a 
behavior  is  a  sequence  of  states.  Each  action  of  the  program  transforms  the 
state.  Nondeterminism,  leading  to  sets  of  behaviors,  appears  when  there  are 
several  choices  of  a  possibile  next  state  from  the  same  current  state. 

It  is  sometimes  argued  that  a  sequence  of  states  cannot  adequately  model 
the  execution  of  a  concurrent  program  because  it  has  no  notion  of  concurrent 
activity,  and  that  one  should  instead  use  a  partially  ordered  set  of  actions. 
However,  a  partially  ordered  set  contains  exactly  the  same  information  as 
the  set  of  all  total  orderings  consistent  with  the  partial  order.  Since  the 
meaning  of  a  statement  is  the  set  of  behaviors,  which  includes  all  possible 
sequences  that  represent  the  real,  partially  ordered  set  of  actions,  nothing 
has  been  lost  by  considering  sequences.  The  basic  assumptions  being  made 
are  that  the  execution  of  a  program  consists  of  discrete  atomic  actions,  and 
the  possible  effect  of  an  atomic  action  depends  only  upon  the  current  state. 
It  appears  that  any  digital  system  can  be  accurately  modeled  in  this  way  by 
making  the  atomic  actions  small  enough  and  including  enough  information 
in  the  current  state. 

It  turns  out  that  to  define  the  semantics  of  concurrent  languages,  one 
needs  more  information  about  a  behavior  than  just  the  sequence  of  states; 
one  must  also  know  “who”  performed  the  actions.  For  example,  the  natu¬ 
ral  definition  of  a  fair  cobegin  states  that  in  each  infinite  behavior,  every 
nonterminating  process  performs  infinitely  many  actions.  Formalizing  this 
definition  requires  the  ability  to  decide  which  process  performs  each  action. 
I  will  therefore  define  a  behavior  to  be  a  sequence  of  the  form: 


where  the  a,-  are  states  and  the  a,-  are  actions.  Fairness  of  a  cobegin  can  be 
expressed  by  stating  that  for  every  process  and  every  n:  if  there  is  no  state 
a,  with  i  >  n  in  which  the  process  has  terminated,  then  infinitely  many  of 
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of  5.  For  example,  .MjSi;  S;]  should  be  defined  in  terms  of  .M[[Si]  and 
I  will  say  that  a  semantics  with  this  property  is  compositional.1 

When  defining  a  formal  semantics,  the  first  thing  one  has  to  decide  is 
what  kind  of  object  X[S|  should  be.  The  execution  of  a  statement  in  a 
sequential  program  is  usually  considered  to  start  in  some  input  state  and 
produce  an  output  state,  and  .MjSj  is  defined  to  be  a  mathemtical  object 
that  describes  the  relation  between  the  input  and  the  output  states.  One 
way  of  doing  this  is  to  define  to  be  a  set  of  ordered  pairs  of  states. 

Concurrent  programs  cannot  be  described  with  such  a  simple  input/out¬ 
put  semantics.  Consider  the  following  two  program  statements,  where  angle 
brackets  denote  indivisible  atomic  operations. 

1 .  ( x  :=  x  +  1 } 

2.  begin  {x  :=  x  +  y); 

( x  :=  x  -  y  +  1  > 

end 

These  statements  both  have  the  same  relation  between  input  and  output 
states — they  both  increment  the  value  of  x  by  one.  However,  they  are  not 
equivalent  when  used  as  part  of  a  concurrent  program.  Executing  the  first 
always  has  the  efTect  of  adding  one  to  x,  but  executing  the  second  can  have 
a  very  different  effect  if  the  value  of  y  is  changed  by  some  other  process 
between  the  two  assignments  to  x. 

A  semantics  for  a  concurrent  programming  language  must  define  the 
meaning  of  a  statement  in  terms  of  its  behavior.  There  are  two  fundamen- 
tally  different  approaches  to  doing  this.  The  first  approach  is  to  define  the 
meaning  of  a  statement  S  in  terms  of  the  effects  it  produces  that  are  “visi¬ 
ble”  outside  5.  For  example,  in  a  shared-variable  language,  the  only  visible 
effects  of  executing  a  statement  are  changes  to  shared  variables.  The  alter¬ 
native  approach  to  defining  the  semantics  of  concurrent  languages  defines 
the  meaning  of  a  statement  in  terms  of  complete  behaviors,  which  include 
all  the  effects  of  a  statement’s  actions,  whether  externally  visible  or  not.  In 
most  languages,  these  invisible  effects  include  changes  to  the  control  state 
(the  values  of  “program  counters”). 

An  approach  that  mentions  only  visible  effects  is  very  appealing,  and 
it  has  been  taken  by  a  number  of  researchers  [3,11].  For  many  years,  I  re¬ 
garded  it  as  the  proper  way  to  think  about  programs,  and.  found  it  unnatural 

'The  terms  denotational,  tynlax-dirtetcd,  and  modular  have  also  been  used  to  denote  this 

property. 


2  An  Introduction  to  Semantics 

2.1  What  Are  Semantics? 


The  syntax  of  a  programming  language  defines  the  set  of  syntactically  well- 
formed  programs  of  that  language.  However,  a  program  is  more  than  just 
a  string  of  characters;  there  should  be  a  well-defined  set  of  possible  results 
of  executing  the  program.  The  purpose  of  a  semantics  is  to  assign  a  math¬ 
ematical  meaning  to  each  syntactically  correct  program  that  describes  the 
effect  of  executing  it. 

I  will  regard  a  program  fl  to  be  a  syntactic  object,  and  denote  by  .M([n] 
the  mathematical  object  denoting  its  meaning.  To  define  a  formal  semantics, 
one  must  specify  the  mapping  II  —*  .Mfll]. 

What  is  the  purpose  of  a  formal  semantics?  One  purpose  is  to  help  us  to 
understand  the  language.  However,  “understanding”  is  too  vague  to  usefully 
characterize  a  formalism.  I  propose  that  a  formal  semantics  should  provide 
a  formal  basis  for  the  following: 

1 .  Deducing  properties  of  a  program  written  in  the  language. 

2.  Deciding  if  a  compiler  is  correct,  given  a  formal  semantics  for  the 
target  language  into  which  the  programs  are  compiled. 

A  semantics  should  provide  a  formal  foundation,  but  not  necessarily  a.prac- 
tical  method,  for  doing  these  things.  A  method  for  deducing  properties  of 
a  program  is  called  a  proof  system.  A  proof  system  is  used  to  decide  if  a 
program  works  properly;  a  semantics  is  used  to  decide  if  a  programming 
language  is  defined  properly.  One  wants  to  reason  about  programs  at  a  high 
level,  hiding  as  much  detail  of  the  language  as  possible;  a  semantics  should 
expose  the  language  details.  Although  a  semantics  allows  one,  in  principle, 
to  verify  properties  of  programs,  its  real  purpose  is  to  explain  the  language. 
A  semantics  should  be  used  to  verify  the  correctness  of  a  proof  system;  it 
need  not  provide  a  practical  method  for  reasoning  about  programs. 

Programs  can  be  very  large  and  complicated.  We  want  to  reduce  the 
problem  of  understanding  a  complex  program  to  that  of  understanding  its 
components.  The  meaning  of  a  program  should  therefore  be  defined  in 
terms  of  the  meanings  of  its  components.  We  must  therefore  define  the 
meaning  not  just  of  an  entire  program,  but  of  individual  components — 
usually  individual  program  statements.  So,  ,M[[SJ  must  be  defined  for  any 
program  statement  5,  and  it  must  be  defined  in  terms  of  the  substatements 


The  first  idea  was  developed  by  Susan  Owicki  and  myself  in  the  late 
1970’s,  and  was  published  in  [6].  (It  was  developed  independently,  in  dif¬ 
ferent  contexts,  by  other  researchers  (lj.)  The  second  and  third  ideas  were 
developed  by  me  shortly  afterwards.  The  second  was  also  used  in  [6],  though 
not  featured  prominently  there.  The  third  idea  has  never  appeared  in  print, 
though  I  have  talked  about  it  in  lectures  starting  in  1981.  The  fourth  idea 
was  discovered  by  Fred  Schneider  and  myself  in  the  spring  of  1984  [10].  The 
fifth  idea  has  been  present  in  all  of  my  work  on  temporal  logic,  starting 
with  [5].  I  was  originally  led  to  it  by  my  philosophical  objections  to  the 
“next  time”  operator;  only  later  did  I  recognize  its  practical  significance  [8]. 

The  first  two  ideas  were  used  in  [14],  but  they  are  not  enough  to  permit 
a  compositional  semantics  based  upon  a  simple  temporal  logic.  Combined 
with  the  third  idea,  they  do  permit  a  compositional  semantics,  but  a  se¬ 
mantics  that  I  did  not  find  satisfying.  It  seemed  like  a  large,  complicated 
structure  had  to  be  erected  solely  to  reason  about  program  control,  mak¬ 
ing  the  enterprise  of  dubious  merit.  It  was  the  fourth  idea  that  gelled  the 
method  into  a  coherent  form.  The  apparatus  for  handling  program  control 
was  no  longer  an  ad  hoc  “Kludge”.  Rather,  it  was  the  appropriate  structure 
to  deal  with  aliasing.  Aliasing  was  not  considered  in  other  approaches,  but 
it  is  a  problem  that  must  be  dealt  with  in  any  realistic  language,  if  only 
to  handle  procedure  calls.  The  fifth  idea  is  not  needed  for  the  semantics 
itself;  in  fact  the  semantics  would  be  somewhat  easier  to  understand  had  I 
abandoned  it  and  employed  the  next-time  operator  favored  in  most  other 
temporal  logic  approaches.  However,  allowing  stuttering  actions  enables  the 
semantics  to  address  the  practical  issue  of  what  it  means  for  a  compiler  to 
be  correct. 

In  this  paper,  I  develop  these  five  ideas,  and  show  how  they  lead  to  a 
method  for  defining  the  semantics  of  concurrent  programming  languages. 
A  complete  semantics  is  given  only  for  a  simple  language.  However,  the 
approach  is  “meta-compositional”  in  the  sense  that  the  meaning  of  each 
language  construct  is  defined  independently  of  the  other  constructs  in  the 
language.  The  semantics  of  a  richer  language  can  be  given  by  defining  the 
meanings  of  its  additional  constructs,  without  changing  the  meanings  of  the 
constructs  from  the  simple  language.  (This  is  not  the  case  in  [14]  where, 
for  example,  the  axioms  for  the  assignment  statement  would  be  invalid  if 
an  unfair  cobegin  were  added  to  the  language.)  I  will  indicate  the  power 
of  my  method  by  informally  describing  how  the  meanings  of  some  more 
complicated  language  constructs  can  be  defined. 


1  An  Introduction  to  this  Paper 

A  large  body  of  research  on  the  logic  of  concurrent  programs  may  be  char¬ 
acterized  as  the  “axiomatic”  school.  Members  of  this  school  reason  about 
safety  properties  (“something  bad  never  happens”)  in  terms  of  invariance, 
and  liveness  properties  (“something  good  eventually  does  happen”)  using 
temporal  logic. 

While  they  are  quite  successful  at  proving  properties  of  a  given  program, 
axiomatic  methods  have  not  provided  a  satisfactory  semantics  for  concurrent 
programming  languages.  Axiomatic  methods  usually  reason  about  the  entire 
program,  while  a  semantics  should  be  compositional — deriving  the  meaning 
of  a  program  from  the  meanings  of  its  components.  Even  the  Generalized 
Hoare  Logic  described  in  [4]  and  [9],  which  looks  compositional,  actually 
assumes  a  context  of  a  complete  program.  The  only  attempt  we  know  of 
at  a  truly  compositional  axiomatic  semantics  for  concurrent  programs  that 
handles  both  safety  and  liveness  properties  is  given  in  [14).  However,  while 
it  is  axiomatic  in  a  strict  logical  sense,  that  approach  is  not  in  the  spirit 
of  the  axiomatic  school  because  it  essentially  defines  a  new  temporal  logic 
operator  for  every  programming-language  construct. 

In  this  paper,  I  present  a  new  compositional,  truly  axiomatic  semantics 
for  concurrent  programming  languages.  It  is  based  upon  temporal  logic,  but 
employs  five  fundamental  ideas  beyond  those  found  in  most  temporal  logic 
methods: 

1.  The  addition  of  action  predicates  to  describe  “who”  performs  an  ac¬ 
tion. 

2.  Defining  an  assertion  to  be  true  of  a  statement  only  if  it  is  true  of 
every  program  containing  that  statement. 

3.  The  introduction  of  renaming  operations  that  map  an  assertion  about 
a  statement  5  into  an  assertion  about  a  larger  statement  containing 
5  as  a  substatement. 

4.  Defining  the  relations  between  control  points,  described  in  [4)  as  state 
predicates,  to  be  aliasing  relations  among  variables. 

5.  Allowing  “stuttering”  actions,  so  an  atomic  operation  is  represented 
by  a  finite  sequence  of  actions,  only  the  last  one  having  any  effect. 
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priority  is  a  mechanism,  not  an  end  in  itself.  In  the  inter¬ 
nal  specification,  we  give  writers  priority  not  because  cor¬ 
rectness  requires  them  to  have  precedence,  but  rather  to 
ensure  that  they  receive  adequate  service.  For  example, 
a  common  use  of  writer  priority  is  to  guarantee  absence 
of  starvation— a  waiting  writer  eventually  writes  despite  a 
continual  stream  of  readers.  What  we  need  to  specify  is 
the  required  service,  not  the  mechanism  used  to  achieve  it. 
The  absence  of  starvation  belongs  to  a  fundamental  class 
of  properties,  known  as  liveness  properties,  that  are  easily 
expressed  in  temporal-logic  based  methods  like  the  ones  of 

[8],  [11],  [13],  (16],  [17],  and  [18].  It  is  the  basic  requirement 
that  should  be  specified,  not  the  priority  mechanism  used 
to  achieve  it. 
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sequences  consisting  of  a  finite  number  of  heads  and  tails  followed  by  nothing 
but  coin  lost  actions. 

This  is  a  perfectly  reasonable  example,  which  the  reader  may  find  more 
familiar  if  he  replaces  coin  lost  by  abort  program.  A  behavioral  semantics  for 
this  way  of  combining  processes  would  require  a  more  complicated  definition 
of  fair  interleaving,  and  a  formal  statement  of  this  definition  would  look  a 
lot  like  a  temporal  logic  axiom.  Fair  interleaving  is  not  a  simple  concept. 
One  particular  type  of  fair  interleaving  has  been  used  so  commonly  that  we 
tend  to  take  it  for  granted  and  forget  that  we  have  never  seen  a  constructive 
definition  of  it. 

Fairness  does  not  appear  to  be  a  constructive  concept.  One  specifies 
fairness  by  adding  axioms  to  exclude  unfair  behaviors  rather  than  by  explic¬ 
itly  constructing  only  the  fair  ones.  Infinite  objects,  such  as  behaviors,  are 
constructed  as  limits  of  finite  approximations — a  method  often  described  as 
“denotational”.  This  does  not  work  with  fairness  because  there  exist  se¬ 
quences  of  fair  behaviors  whose  limits  are  unfair — for  example,  let  01,02, . . . 
be  the  sequence  of  coint-flipping  behaviors  in  which  all  actions  of  on  are 
heads,  except  for  every  2 nth  action,  which  is  a  tail.  Each  on  is  fair,  but  the 
limit  as  n  goes  to  infinity  is  the  behavior  having  only  heads,  which  is  unfair. 

The  topological  approach  of  (2]  solves  this  problem  by  considering  only 
convergent  sequences  and  defining  a  topology  in  which  sequences  like  the 
above  diverge.  However,  one  might  view  this  approach  as: 

Construct  all  sequences  obtainable  from  the  actions  and  throw 

away  those  that  do  not  converge. 

This  looks  suspiciously  like  the  more  overtly  axiomatic  approach.  The  whole 
distinction  between  constructive  and  axiomatic  methods  is  probably  illusory, 
disappearing  when  methods  are  examined  closely  enough. 

2.4  Programs  and  Implementations 
2.4.1  Correctness  of  an  Implementation 

One  question  that  a  semantics  of  a  programming  language  should  answer  is: 
What  does  it  mean  for  a  compiler  to  be  correct?  Given  a  program  n  in  the 
high-level  language,  the  compiler  transforms  it  into  a  program  it  in  some 
lower-level  language.  Correctness  of  the  compiler  means  that  it  is  a  correct 
implementation  of  n,  but  what  does  that  mean?  To  speak  of  correctness, 
we  must  have  formal  semantics  for  both  the  high-level  and  the  low-level 


languages,  so  .MfTI]]  and  M|tt]  are  defined.  However,  this  is  not  enough  to 
determine  what  it  means  for  X|[7r|  to  represent  a  correct  implementation  of 

x[nj. 

Consider  the  case  of  sequential  programs,  in  which  the  semantics  of  a 
program  is  a  relation  on  the  set  of  program  states,  the  pair  (a,t)  being  in 
the  relation  >ljll]  if  and  only  if  it  is  possible  for  program  II  to  start  in  state 
3  and  terminate  in  state  t.  In  this  case,  Jn]]  and  Mjffj  are  relations  on 
two  different  sets  of  states.  The  states  of  II  specify  the  values  of  program 
variables  like  x  and  y;  the  states  of  n  might  specify  the  values  of  machine 
registers  like  memory  location  3124  or  the  program  counter.  Correct  imple¬ 
mentation  means  that  there  is  a  correspondence  between  the  sets  of  states 
of  II  and  jr  such  that,  under  this  correspondence,  every  possible  execution 
of  it  is  a  possible  execution  of  n. 

More  formally,  to  establish  a  correspondence  between  the  semantics  of 
the  two  sequential  programs,  we  must  define  a  mapping  F  from  the  states 
of  it  to  the  states  of  II.  For  example,  suppose  the  variable  x  in  II  of  type 
integer  is  implemented  in  it  as  a  two-byte  integer  stored  in  bytes  3124  and 
3125  of  memory.  If,  in  a  state  a  of  it,  bytes  3124  and  3125  have  the  values 
12  and  97,  then  the  value  of  x  in  the  state  F(a)  of  II  is  12  x  256  +  97.  In 
general,  correctness  of  the  implementation  means  that  for  each  pair  (a,  t)  in 
M[it],  the  pair  (F(s),F(t))  must  be  in  Mjflj. 

What  about  concurrent  programs?  As  we  have  seen,  the  meaning  of 
a  concurrent  program  must  be  expressed  in  terms  of  its  behavior — either 
directly,  with  a  behavioral  semantics,  or  indirectly  with  axioms  about  its 
behavior.  Let  us  therefore  consider  first  a  behavioral  semantics,  in  which 
X[IIJ  and  X|[jr|  are  sets  of  behaviors.  Intuitively,  it  is  a  correct  implemen¬ 
tation  of  II  if  every  possible  behavior  of  it  represents  a  possible  behavior  of 
II.  We  therefore  need  some  way  of  interpreting  behaviors  of  it  as  possible 
behaviors  of  II — that  is  a  mapping  F  such  that  for  any  behavior  <x  in  Xjn|, 
F(a)  is  a  sequence  of  states  and  actions  of  II.  We  can  then  say  that  it  is  a 
correct  implementation  of  II  if,  for  every  o  in  XJtt],  F(<t)  is  in  X[II]. 

In  defining  this  mapping  F,  we  are  faced  by  the  problem  that  IT  and  it 
may  have  different  grains  of  atomicity.  An  atomic  operation  of  II  may  be 
implemented  by  a  sequence  of  42  atomic  operations  of  it.  For  example,  the 
atomic  operation 

(x  :=  x+  1 ) 

of  II  might  be  implemented  in  it  by  42  machine-language  operations.  More¬ 
over,  interleaved  among  these  42  atomic  operations  of  it  might  be  other 


machine-language  operations  that  belong  to  the  implementation  of  an  oper¬ 
ation  from  a  different  process  of  II.  It  would  therefore  seem  that  the  mapping 
F  must  be  quite  complicated,  taking  sets  of  actions  into  single  actions. 

There  is  very  simple  solution  to  this  problem — we  require  that  to  every 
action  of  it  there  correspond  a  single  action  of  II.  The  execution  of  a  single 
atomic  operation  of  II  might  therefore  be  represented  by  42  actions  in  a 
behavior  in  ^(IIJ.  The  first  41  of  these  actions  will  be  “stuttering”  actions 
that  do  not  change  the  state  of  II;  the  42nd  will  do  all  the  work.  This  makes 
it  conceptually  very  easy  to  define  the  mapping  F  from  behaviors  of  n  to 
behaviors  of  II.  As  in  the  sequential  case,  there  must  be  a  mapping  F  from 
states  of  it  to  states  of  II.  We  also  assume  that  F  maps  actions  of  it  to 
actions  of  II — for  example,  every  machine-language  instruction  executed  by 
it  corresponds  to  the  execution  of  some  atomic  operation  of  II.2  To  extend 
F  to  a  mapping  on  behaviors,  if  a  is  the  behavior 


of  it,  we  define  F(a)  to  be  the  behavior 

F(s0)  — 1  Fl*,)^-.. 

The  implementation  is  correct  if,  for  every  behavior  a  of  -M|7t|,  F(o)  is  a 
behavior  in  M|IIJ. 

This  seems  nice  in  theory,  but  how  can  it  be  achieved  in  practice?  The 
first  41  machine-language  operations  in  the  implementation  of  the  atomic 
assignment  must  change  the  state  in  such  a  way  that  they  these  changes  are 
invisible  when  viewed  at  the  higher  level.  More  precisely,  the  41  intermediate 
states  of  the  computation  must  all  be  mapped  by  F  into  the  same  state  as 
the  starting  state.  How  is  this  possible? 

A  complete  answer  to  this  question  is  beyond  the  scope  of  this  paper.  The 
trick  lies  in  the  definition  of  F,  which  must  “unscramble”  the  intermediate 
states  in  the  appropriate  way.  I  will  not  explain  here  how  it  is  done.  I 
will  only  mention  that,  while  it  sounds  like  magic,  it  in  fact  is  a  simple 
extension  of  the  basic  idea  of  invariance  that  underlies  most  concurrent 

2  A  single  machine-language  instruction  could  actually  be  used  in  the  implementation  of 
several  atomic  actions  of  IT — for  example,  if  it  were  part  of  a  subroutine  called  during 
the  execution  of  several  different  statements  of  IT.  The  mapping  F  should  therefore 
take  state,  action  pairs  into  actions,  so  the  action  a,-  of  k  is  mapped  into  the  action 
F(#,_i,a,)  of  II.  In  other  words,  the  state  of  k  determines  which  atomic  statement  of 
II  is  being  executed  by  the  execution  of  a  machine-language  statement. 
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program  verification.  An  explanation  and  examples  can  be  found  in  [6]  and 

[8]- 

I  won’t  consider  the  problem  of  compiler  correctness.  The  purpose  of 
this  discussion  is  to  point  out  that  in  order  to  permit  a  simple  definition 
of  correctness  of  an  implementation,  I  cannot  define  a  semantics  in  which 
the  execution  of  an  atomic  program  statement  is  always  represented  as  a 
single  atomic  action.  I  must  allow  “stuttering”  actions.  In  the  action-axiom 
semantics,  the  specification  of  an  action  a  must  allow  a  finite  series  of  null 
transitions  s  s  as  well  as  the  final  action  a  -2U  t  that  “does  the  work”. 

I  have  described  correctness  of  an  implementation  in  terms  of  a  be¬ 
havioral  semantics,  where  is  a  set  of  behaviors.  In  an  action-axiom 

semantics,  the  meaning  .Min)  of  a  program  II  is  a  set  of  axioms  that  deter¬ 
mines  the  set  of  possible  behaviors.  Section  5.7  explains  how  this  concept 
of  correctness  is  translated  into  a  relation  between  the  sets  of  axioms  X|II] 
and  M|[jr|.  The  only  observation  I  will  make  here  is  that  the  axioms  of 
must  permit  stuttering  actions.  More  precisely,  these  axioms  should  not  be 
able  to  distinguish  stuttering;  if  an  axiom  is  true  for  a  behavior  a,  then  it 
should  also  be  true  for  the  behavior  obtained  from  a  by  adding  stuttering 
actions.  This  will  be  guaranteed  by  using  a  temporal  logic  in  which  no 
formula  can  distinguish  stuttering — a  temporal  logic  with  no  “next-time” 
operator. 

2.4.2  The  Interface 

The  semantics  of  a  program  is  traditionally  defined  by  describing  how  it 
affects  the  values  of  variables.  However,  program  variables  are  internal  to 
the  program;  all  that  a  user  sees  is  what  he  types  into  the  program  and  what 
the  program  types  out  to  him.  A  semantics  of  a  program  should  describe 
its  input  and  output,  not  just  how  it  affects  internal  objects  like  variables. 

Given  the  machine-dependence  of  most  input  and  output,  an  explicit 
semantics  for  input  and  output  seems  like  a  useless  exercise.  Instead,  ob¬ 
serve  that  input  and  output  can  be  representend  by  variables.  A  terminal 
screen  can  be  represented  as  a  Boolean  array,  each  element  representing  the 
presence  or  absence  of  light  at  one  point  on  the  screen.  Keyboard  input 
can  be  simulated  through  a  variable  whose  value  represents  the  sequence  of 
characters  that  have  been  typed  but  not  yet  processed.  I  will  use  the  term 
interface  variables  to  describe  variables  that  represent  input  and  output. 

In  general,  an  interface  variable  describes  the  interaction  between  the 
program  and  its  environment.  They  are  global  or  free  variables,  in  contrast 


to  the  local  or  bound  variables  that  are  declared  in  ordinary  program  dec¬ 
larations.  For  example,  variables  declared  in  a  Pascal  var  declaration  are 
local. 

Let  us  again  consider  the  mapping  F,  introduced  above  to  define  what 
it  means  for  a  lower-level  program  ir  to  be  correct  implementation  of  a 
higher-level  program  II.  Recall  that  F  describes  how  the  variables  of  n  are 
implemented  in  terms  of  the  “variables”  of  ir — the  machine  registers,  if  it  is 
a  machine-language  program.  We  really  don’t  care  how  the  local  variables 
of  II  are  implemented,  since  they  are  not  externally  visible.  The  compiler  is 
free  to  implement  local  variables  any  way  it  wishes. 

The  compiler  does  not  have  such  freedom  in  its  implementation  of  in¬ 
terface  variables.  The  implementation  of  the  interface  variables  must  be 
defined  a  priori  if  the  program  is  to  interact  with  its  environment  in  a  use¬ 
ful  way.  For  example,  suppose  that  the  terminal  screen  is  represented  by 
a  Boolean  array.  The  semantics  of  the  program  II  would  provide  no  infor¬ 
mation  about  real  output  if  the  compiler  could  define  the  array  elements  to 
represent  completely  arbitrarily  points  on  the  screen — or  to  represent  the 
values  of  arbitrary  one-bit  registers  in  the  machine. 

I  have  considered  the  implementation  of  the  states  of  II  in  terms  of  states 
of  7 r,  but  what  about  the  implementation  of  actions?  Just  as  there  are  local 
and  interface  state  functions,  there  are  internal  and  external  actions.  Most 
actions  in  a  program  behavior  are  internal,  being  caused  by  program  execu¬ 
tion.  However,  some  actions  represent  operations  external  to  the  program — 
for  example,  the  actions  that  represent  the  entering  of  an  input  character. 
The  semantics  of  n  does  not  distinguish  this  operation,  which  changes  the 
value  of  the  interface  variable  representing  the  input  buffer,  from  program 
operations  that  change  the  value  of  variables — for  example,  the  program  op¬ 
eration  that  removes  a  character  from  the  input  buffer.  The  compiler  is  free 
to  implement  internal  actions  of  II  by  any  internal  actions  of  it.  However, 
the  external  actions  of  II  must  be  implemented  by  fixed  actions  of  it,  which 
may  be  internal  or  external.  For  example,  the  sequence  of  actions  of  II  that 
add  a  character  to  the  input  buffer  may  be  implemented  by  a  sequence  of 
actions  external  to  it,  representing  external  operations  that  put  the  charac¬ 
ter  into  an  input  register  and  actions  of  it  that  move  the  character  from  the 
input  register  into  the  memory  registers  that  implement  the  input  buffer. 
The  compiler  would  be  of  little  use  if  it  could  implement  the  operation  of 
typing  a  character,  defined  in  the  semantics  of  n  simply  as  an  operation  that 
changes  the  variable  representing  the  input  buffer,  as  an  internal  operation 
of  it  that  adds  a  randomly  chosen  character  to  the  buffer. 


Thus,  the  representation  of  local  variables  and  internal  actions  of  IT 
by  F  may  be  arbitrary,  but  the  representation  of  interface  variables  and 
external  actions  must  be  fixed.  The  meaning  XJFIJ  of  II  can  be  defined  in  a 
completely  machine-independent  fashion.  The  machine  dependency,  which 
exists  for  any  real  compiler,  is  contained  in  the  details  of  how  interface 
variables  and  external  actions  are  to  be  implemented. 

Thus  far,  I  have  been  talking  only  about  implementing  a  complete  pro¬ 
gram  n.  We  should  consider  the  problem  of  implementing  a  single  statement 
5.  In  this  case,  all  the  global  (undeclared)  variables  of  S  must  be  regarded 
as  interface  variables,  and  their  implementations  must  be  fixed  a  priori.  For 
example,  if  statements  S  and  T  were  to  be  implemented  independently,  their 
implementations  could  be  combined  to  implement  S;T  only  if  a  variable  x 
common  to  both  were  implemented  as  the  same  set  of  machine  registers. 

Of  course,  one  is  seldom  interested  in  implementing  a  single  statement 
of  a  program.  These  considerations  would  apply  to  a  language  that  allows 
separate  compilation  of  components  such  as  subroutines.  I  will  not  consider 
the  problem  of  separate  compilation.  My  purpose  in  discussing  implemen¬ 
tation  of  individual  statements  is  to  point  out  that  the  concept  of  global 
and  local  variables  occurs  at  all  levels  of  a  program.  Variables  global  to  a 
statement  S  may  be  local  to  a  larger  statement  containing  S. 


3  The  Programming  Language 

The  goal  of  this  paper  is  to  explain  how  the  semantics  of  any  programming 
language  can  be  defined,  and  not  to  give  a  complete  semantics  for  aparticular 
language.  However,  to  show  how  the  formalism  works,  it  is  helpful  to  define 
rigorously  the  semantics  of  some  language.  I  will  therefore  formally  define 
the  semantics  of  a  simple  language  called  L,  and  will  indicate  informally  how 
the  semantics  of  language  primitives  other  than  those  in  L  can  defined. 

The  language  L  contains  an  atomic  assignment  statement — one  whose 
execution  is  an  indivisible,  atomic  action.  L  has  the  usual  sequential  control 
structures:  concatenation  ( ; ),  if  and  while  statements,  plus  a  fair  cobegin. 
The  tests  in  while  and  if  statements  are  also  taken  to  be  atomic.  L  has  a 
new  statement  that  declares  a  local  variable,  so 

new  x  :  integer  in  5  ni 

declares  a:  to  be  a  local  variable  of  type  integer  whose  scope  consists  of  the 
statement  5.  The  new  statement  has  an  optional  init  clause  to  specify  the 
initial  value,  so 

new  x  :  integer  init  2  *  x  in  5  ni 

declares  that  the  initial  value  of  *  in  5  is  twice  the  value  of  the  variable 
x  whose  scope  includes  the  new  statement.  The  assignment  of  the  initial 
value  to  x  is  assumed  to  be  an  atomic  action.  The  new  statement  also  has 
an  optional  alias  clause  that  is  used  to  declare  that  the  new  variable  is  the 
alias  for  something  else.  For  example, 

new  x  :  integer  alias  y  in  5  ni 
declares  x  to  be  an  alias  for  y. 

It  may  seem  strange  to  introduce  aliasing — a  concept  usually  ignored 
in  simple  examples — in  the  language  L.  Aliasing  is  an  important  concept 
because  it  underlies  the  semantics  of  procedure  calls.  If  proc  is  a  procedure 
defined  with  single  integer-valued  a  call-by-name  parameter  param,  then  the 
call  proc(arg)  can  be  simulated  by  the  statement 

new  param  :  integer  alias  ary  in  S  ni 

where  S  is  the  body  of  proc.  (Call  by  value  and  call  by  reference  can  be 
simulated  with  call  by  name  through  the  use  of  auxiliary  variables.) 

For  reasons  that  will  be  clear  later,  the  concept  of  aliasing  is  central 
to  our  semantics,  and  we  will  need  to  understand  a  more  general  kind  of 
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aliasing  than  real  programming  languages  usually  allow.  In  particular,  L 
will  allow  a  variable  to  be  aliased  to  an  expression.  To  understand  wbat 
that  means,  consider  the  declaration 

new  /  :  real  alias  9  *  c/5  +  32  in  S  ni 

In  this  case,  we  can  think  of  /  and  c  as  representing  a  single  temperature, 
where  /  is  its  value  in  degrees  Farenheit  and  c  is  its  value  in  degrees  Celsius. 
The  two  assignment  statements  /  :=  32  and  c  :=  0  have  exactly  the  same 
effect;  executing  either  one  changes  the  value  of  /  to  32  and  the  value  of  c 
to  zero. 

As  another  example,  assume  a  type  gaussian  which  represents  a  Gaus¬ 
sian  integer — a  number  of  the  form  m  +  rty/- T,  where  m  and  n  are  integers. 
If  x  and  y  are  variables  of  type  integer,  then 

new  z  :  gaussian  alias  x  +  y  *  yf-i  in  S  ni 

defines  z  to  be  a  variable  of  type  gaussian  whose  real  part  is  aliased  to  x 
and  whose  imaginary  part  is  aliased  to  y.  Assigning  a  value  to  2  in  S  also 
assigns  values  to  x  and  y  so  that  the  relation 

z  =  x  +  y  *  \/-T 

holds  throughout  the  execution  of  5.  Similarly,  changing  the  value  of  x  in 
S  also  changes  the  value  of  z. 

In  the  examples  of  alias  clauses  given  so  far,  assigning  a  value  to  any 
variable  produces  a  well-defined  result.  However,  this  need  not  be  the  case. 
Inside  the  body  5  of  the  statement 

new  c  :  integer  alias  a  +  b  in  5  ni 

assigning  a  value  to  a  or  b  changes  the  value  of  c  in  the  obvious  way,  but 
what  is  the  result  of  assigning  a  value  to  c?  I  define  an  assignment  to  c  to 
be  a  nondeterministic  statement  that  can  change  the  values  of  a  and  b  in 
any  way  such  that  a  +  6  equals  the  new  value  of  c. 

However,  I  will  assume  that  the  aliasing  relations  are  such  that  they 
can  always  be  maintained  by  the  proper  choice  of  values.  More  precisely,  a 
program  is  considered  illegal  if  its  execution  would  force  the  aliasing  relations 
to  be  violated.  For  example,  the  statement 

new  6  :  integer  alias  y/a  in  5  ni 


is  illegal  if,  at  any  time  during  its  execution,  the  value  of  a  is  not  a  perfect 
square. 

This  approach  to  aliasing  is  similar  to  the  one  1  will  take  for  type 
constraints — namely,  a  program  is  illegal  if  its  execution  would  force  a  type 
violation.  For  example,  the  statement 

new  6  :  boolean  Init  ->c  in  . . . 

is  illegal  in  any  context  in  which  c  is  not  declared  to  be  of  type  boolean. 

While  typing  consistency  is  easy  for  a  compiler  to  enforce  in  language 
L,  the  consistency  of  aliasing  relations  can  be  determined  at  compile  time 
only  if  the  kind  of  expression  that  can  appear  in  an  alias  is  restricted  in 
some  way.  In  fact,  some  restriction  is  obviously  necessary  if  the  compiler  is 
to  have  any  chance  at  compiling  the  code.  Those  restrictions  are  irrelevant 
to  our  semantics,  so  they  are  not  discussed. 

The  basic  syntax  of  L  :s  given  by  the  syntax  diagrams  in  Figure  1.  I 
will  not  bother  to  give  a  formal  syntax  for  identifiers.  The  only  types  that  I 
will  use  in  L  are  integer  and  boolean.  Expressions  are  assumed  to  be  the 
usual  ones  constructed  from  variable  names  and  the  ordinary  operations  on 
integers  and  booleans — for  example,  an  expression  like 

(x  *  y  +  z  =  17)  D  (x  >  y  V  -16) 

I  will  enclose  if  and  while  tests,  assignment  statements,  and  the  init  clause 
of  a  new  statement  in  angle  brackets  to  emphasize  their  atomicity. 

In  addition  to  the  usual  information,  the  syntax  diagrams  of  Figure  1 
also  have  labels  attached  to  the  nonterminal  components.  These  labels  are 
called  primitive  selectors.  A  primitive  selector  identifies  a  component  of  a 
compound  statement — for  example,  the  primitive  selector  then  identifies  the 
“then-clause”  of  an  if  statement.  The  *. .  .*  label  in  the  specifications  of  the 
cobegin  indicates  that  the  primitive  selectors  for  the  clauses  of  a  cobegin 
are  integers,  and  likewise  for  a  list  of  statements. 

In  more  formal  terms,  the  primitive  selectors  label  the  edges  in  the  parse 
tree  of  a  statement  or  program.8  A  selector  for  a  statement  5  is  a  sequence 
of  primitive  selectors  that  represents  a  path  starting  from  the  root  in  5’s 
parse  tree.  A  selector  identifies  a  component  of  a  program  or  statement.  For 
example,  the  selector  else,  body,  2  identifies  the  substatement  ( x  :=  x  +  4 ) 
in  the  following  statement: 

3Trivial  nodes  that  have  only  a  single  son  are  eliminated  from  the  parse  tree,  which  is 
why  there  is  no  primitive  selector  associated  with  the  first  box  in  the  syntax  diagram 
defining  a  statement. 
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program: 


body 


simple  statement: 

lh  rh 


Figure  1:  Basic  syntax  of  language  L. 


More  formally,  given  a  program  or  statement  S,  a  substatement  of  5  consists 
of  a  pair  S,  7,  where  i  is  a  selector  for  5.  A  substatement  of  S  is,  when 
viewed  by  itself,  a  statement.  I  will  often  write  something  like:  “T  is  the 
substatement  S,  7  of  S This  means  that  the  substatement,  when  viewed 
alone,  is  the  same  as  the  statement  T.  However,  T  and  S,  7  are  formally 
two  different  kinds  of  objects — one  is  a  complete  statement  and  the  other  is 
part  of  a  statement. 

The  null  selector  selects  the  entire  statement,  so  “S,”  denotes  5  viewed 
as  a  substatement  of  itself.  Since  “5,"  looks  rather  strange,  I  will  simply 
write  S  to  denote  both  the  entire  statement  5  and  that  statement  viewed 
as  a  substatement  of  itself. 


4  States  and  Actions 


The  meaning  X|5]  of  a  statement  S  will  be  a  set  of  temporal  logic  axioms 
defining  the  behaviors  of  5  and  a  set  of  nontemporal  axioms  defining  its  set 
of  initial  states.  To  give  a  semantics  for  these  axioms,  I  must  define  the  the 
set  S(S)  of  all  possible  states  of  S  and  the  set  ^(S)  of  all  possible  actions 
of  5.  The  initial-state  axioms  then  define  a  set  of  states — namely,  the  set  of 
all  states  in  5(5’)  that  satisfy  those  axioms;  and  the  temporal  axioms  define 
a  set  of  behaviors — namely,  the  set  of  all  sequences 


with  »i  6  S(S)  and  Or,-  6  A(S)  that  satisfy  those  axioms. 

Intuitively,  the  state  of  a  statement  at  some  time  during  its  execution 
contains  all  the  information  needed  to  describe  its  possible  behavior  at  future 
times.  To  define  the  set  S(5),  we  must  consider  what  information  must  be 
in  the  state  of  5. 

4.1  Program  Variables 

The  future  behavior  of  a  program  certainly  depends  upon  the  current  values 
of  its  variables,  so  a  state  must  specify  the  values  of  all  program  variables. 
More  precisely,  a  state  in  S{S)  must  include  a  mapping  val  from  the  set  of 
variables  of  5  to  a  set  of  values.  For  the  simple  language  L,  in  which  all 
variables  are  of  type  integer  or  boolean,  the  set  of  values  consists  of  the 
set  Z  U  {true,  false},  where  Z  denotes  the  set  of  all  integers. 

Let  5  be  the  statement 

cobegin  Sx  D  5;  coend 

and  suppose  that  S\  and  5;  both  contain  new  x  statements.  Each  of  these 
statements  declares  a  different  variable,  but  both  variables  have  the  same 
name  x.  Both  of  the  variables  named  x  may  be  defined  at  the  same  time, 
and  may  have  different  values.  To  facilitate  the  discussion,  I  will  use  the 
term  identifier  to  denote  the  syntactic  object  constituting  the  name  of  a 
variable,  and  the  term  variable  to  denote  the  variable  itself.  Thus,  5  has 
two  different  variables  having  the  same  identifier  z.  This  situation  does  not 
arise  in  a  sequential  program  because,  at  any  instant  during  its  execution, 
there  is  at  most  one  currently  active  variable  for  any  identifier.  However,  it 
does  arise  in  concurrent  programs  and  must  be  considered. 


To  define  val,  we  must  define  the  value  it  assigns  to  each  of  the  variables 
of  5,  which  requires  giving  different  names  to  different  variables.  Assigning 
unique  names  to  variables  is  a  nontrivial  problem,  since  different  variables 
may  be  represented  in  the  program  by  the  same  identifier.  It  is  solved  with 
selectors.  I  let  z(5,7 f)  be  the  name  of  the  variable  with  identifier  z  that 
is  declared  in  a  new  statement  whose  selector  in  5  is  7 — in  other  words, 
where  7  is  the  path  in  the  parse  tree  of  5  leading  to  the  new  statement. 
A  “global”  variable  with  identifier  x — that  is,  the  variable  denoted  by  an 
occurrence  of  the  identifier  x  outside  the  scope  of  any  new  x  statement — is 
given  the  name  z(). 

I  consider  z()  to  be  a  variable  of  any  statement  5,  even  if  the  identifier 
x  never  appears  in  5.  For  example,  suppose  5  is  the  statement: 

(y  :=t/+l  ); 

new  2  :  in  ( z  :=  y  )  ni 

Then  the  variables  of  5  consist  of  the  single  “bound”  variable  2(5,  2)  plus 
the  infinite  set  of  “free”  variables  z(),  y(),  z( ),  . . .,  only  one  of  which  actually 
appears  in  5.  Even  though  the  variable  x()  does  not  appear  in  S,  it  may 
appear  in  other  statements  in  the  complete  program.  The  correctness  of  a 
program  containing 

cobegin  5  Q  T  coend 

may  depend  upon  the  obvious  fact  that  5  does  not  change  the  value  of  x(). 
The  value  of  z()  is  included  as  part  of  5’s  state  so  we  can  say  formally  that 
S  does  not  change  that  value. 

To  summarize,  defining  the  set  of  states  S(S)  of  5  requires  defining  the 
set  of  variables  of  5.  The  variables  of  5  consist  of  the  following: 

•  For  any  new  x  statement  of  5  with  selector  7,  the  variable  named 

“x(s,7r. 

•  For  any  identifier  z,  the  variable  named  “x()”. 

The  mapping  val  assigns  a  value  to  each  of  these  variables. 

The  names  of  variables  come  up  quite  often  when  talking  about  pro¬ 
grams.  If  5  is  a  hundred  page  program,  then  the  name  2(5,7)  takes  up 
one  hundred  pages.  Writing  even  the  simplest  statements  about  5  would 
therefore  require  quite  a  bit  of  paper.  Such  a  practical  consideration  is  as 
irrelevant  for  the  semantics  of  a  programming  language  as  is  the  cost  of 
tape  for  the  theory  of  Turing-machine  computability.  However,  it  does  pose 


a  problem  in  writing  examples,  since  a  simple  assertion  about  a  five-line 
program  might  take  one  or  two  pages.  The  solution  is,  of  course,  to  give 
names  to  statements  and  substatements.  I  will  use  the  ordinary  labeling 
convention  to  do  this.  For  example,  consider  the  program. 

s:  if  ( x  >  0 ) 

then  ( x  :=  x  +  1 ) 
else  t :  new  y 

in  {y  :=  x); 

( x  -=y  +  2) 
ni; 

<*:*  17) 

fi 


The  variable  y  declared  by  the  new  y  statement  will  be  called  simply 
y(t  of  s).  However,  you  should  remember  that  its  complete  formal  name 
is: 


(  if(x  >  0) 


then . . . 


\ 

else ,  1 


4.2  Control  Variables 

There  is  more  to  a  state  than  the  values  of  program  variables.  To  determine 
the  future  behavior  at  some  point  during  the  execution  of  the  statement 

u:  begin  s:  ( x  :=  x  +  l ); 

(»:=»  +  1) 

end 

we  need  to  know  whether  control  is  at  the  beginning  of  statement  $,  at 
the  beginning  of  statement  t,  or  at  the  end  of  statment  t.  Since  the  state 
must  determine  the  statement’s  possible  future  behavior,  it  must  contain 
this  control  information. 

I  will  describe  this  control  information  in  terms  of  the  boolean-valued 
control  variables  at,  in,  and  after.  For  any  substatement  5,7,  there  are 
control  variables  at(5,  7),  in(S,  7),  and  after(S,  7),  where  the  values  of  these 
variables  equal  true  when 

at(S,  7):  control  is  at  the  beginning  of  substatement  5,  7 
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Section  2.4  of  the  dual  mapping  F  applies  equally  well  to  F*,  and  I  will  not 
discuss  further  how  F *  is  actually  constructed. 

Since  temporal  logic  formulas  are  constructed  from  predicates  and  tem¬ 
poral  operators,  there  is  an  obvious  extension  of  F*  to  a  mapping  from 
7£(n)  to  TC(7r).  For  example, 

F*(tn(n,  p)  <  z(n,  *y)  >  0)  =  F*(m(Il,p))  <  F*(x(n,Tf)  >  0) 

It  follows  from  these  definitions  that  for  any  behavior  a  of  n  and  any  formula 

A  in  7£(n): 

<7  |=  F*(A)  s  F(<r)  H  A 

In  terms  of  behaviors,  n  correctly  implements  IT  if,  for  every  possible 
behavior  a  of  n,  F(a)  is  a  possible  behavior  of  II.  For  simplicity,  let  us  ignore 
the  initial-state  specification,  so  the  meaning  M[n]  of  II  in  an  action-axiom 
semantics  is  a  set  of  temporal  logic  axioms,  and  F(ff)  is  a  possible  behavior 
of  n  if  and  only  if  F(< r)  |=  A  is  true  for  all  A  E  .Mill].  But  F(er)  |=  A 
is  true  if  and  only  if  a  f=  F*(A)  is,  so  it  correctly  implements  II  if  and 
only  if  a  |=  F*(A)  is  true  for  all  A  E  M[II]  and  all  behaviors  a  of  it.  The 
behaviors  of  it  consist  of  the  sequences  satisfying  all  the  axioms  of  Miff]. 
It  follows  from  this  that  it  correctly  implements  II  if,  for  every  axiom  A  in 
Mill],  F*(A)  is  implied  by  the  axioms  in  M [7r|.  Thus,  proving  correctness 
of  the  implementation  involves  deducing,  from  the  axioms  for  it,  the  truth 
of  F*(A) — the  translation  of  A  into  an  assertion  about  it — for  every  axiom 
A  in  M[I1]. 

As  explained  in  Section  2.4,  a  compiler  is  free  to  implement  local  vari¬ 
ables  and  internal  actions  in  any  fashion,  but  interface  (global)  variables 
and  external  actions  have  a  fixed  implementation.  The  mapping  F*  is  de¬ 
fined  on  state  predicates  by  defining  F*(v)  in  terms  of  the  variables  of  7r , 
for  every  variable  v  of  II.  The  definition  of  F*(v)  is  arbitrary  for  a  local 
variable  v,  but  is  fixed  for  an  interface  variable.  To  prove  the  correctness  of 
an  implementation,  we  are  allowed  to  define  F*(u)  any  way  we  like  if  t’  is  a 
local  variable,  but  must  use  the  predetermined  definition  if  v  is  an  interface 
variable.  Similar  comments  apply  to  actions. 

I  find  it  helpful  to  think  of  the  semantics  Mfll]  of  II  as  the  specifica¬ 
tion  of  a  lower-level  implementation.  When  viewed  this  way,  there  is  an 
implicit  existential  quantification  over  the  names  of  all  local  variables  and 
internal  actions.  More  precisely,  the  specification  consists  of  the  conjunction 
of  all  the  axioms  in  Mjnl,  with  existential  quantification  over  these  variable 


It  is  the  inability  to  distinguish  stuttering  that  makes  it  easy  to  talk  about 
a  lower-level  program  implementing  a  higher-level  one. 

5.7  Implementation  Mappings 

I  can  now  continue  the  discussion,  begun  in  Section  2.4,  of  what  it  means  for 
a  lower-level  program  to  correctly  implement  a  higher-level  one.  Let  II  be 
the  higher-level  program  and  it  be  its  lower-level  implementation.  From  the 
point  of  view  of  behaviors,  we  saw  that  there  should  be  mappings  F  from 
the  states  and  actions  of  n  to  the  states  and  actions  of  II  so  that  if  a  is  the 
behavior 


of  it,  then  F(cr),  which  is  defined  to  be 

f(»o)  — 1 '/•(..) '2s’- 

is  a  behavior  of  II. 

How  are  the  mappings  F  defined?  In  action-axiom  semantics,  one  never 
mentions  states,  just  state  predicates — mappings  from  the  state  into  a  set 
of  Booleans.  A  state  is  determined  by  the  values  of  all  state  predicates.  To 
define  a  mapping  F  :  S(7r)  — *  S (II),  one  defines  a  mapping  F *  that  maps 
state  predicates  of  II  into  state  predicates  of  it.  Intuitively,  F*  defines  the 
state  predicates  of  II  in  terms  of  the  state  predicates  of  jr.  For  example, 
F*(i(n,*y)  >  0)  is  the  state  predicate  of  n  that  “implements*  the  state 
predicate  x(II,  7)  >  0  of  II;  in  other  words,  it  is  the  translation  of  the  high- 
level  statement  that  the  value  of  the  variable  1(11,7)  is  positive  into  a  lower- 
level  statement  involving  the  values  of  memory  registers,  program  counters, 
etc.  Defining  the  mapping  F *  requires  describing  how  the  variables  (both 
program  and  control  variables)  of  II  are  implemented  by  the  “variables* 
(machine  registers)  of  it.  The  mappings  F  and  F *  are  related  by 

s^F’(P)  =  F(#P 

for  any  state  3  in  S (?r)  and  state  predicate  P  in  P£(fl). 

In  a  similar  way,  F*  is  defined  to  map  action  predicates  of  II  into  action 
predicates  of  n,  so  F *  :  P£(II)  — *  PZ(n).  Finding  the  mapping  F *  is 
the  heart  of  the  proof  that  n  correctly  implements  II.  The  discussion  in 


a  f=  A  =  true  for  all  a  €  E.  The  valid  formulas  for  a  program  S  are  those 
that  are  valid  for  the  set  of  all  behaviors  of  S. 

Note  that  false  is  true  if  and  only  if  £  is  the  empty  set.  The  semantics 
1  give  can  produce  contradictory  sets  of  axioms  for  a  program — axioms  from 
which  one  can  deduce  the  formula  false.  This  is  not  an  inconsistency  in  the 
system;  rather  it  is  an  indication  that  there  are  no  legal  behaviors  of  the 
program,  so  the  program  is  illegal.  This  will  be  the  case,  for  example,  if  a 
program  assigns  a  boolean  value  to  a  variable  of  type  integer. 

I  consider  the  notion  f=£  of  semantic  validity  only  for  sets  E  having  the 
property  that  for  any  a  €  £  and  any  n  >  0;  (7+n  €  £.  Intuitively,  this 
means  that  the  temporal  logic  does  not  assume  any  preferred  starting  state. 
Formally,  this  means  that  the  truth  of  A  implies  the  truth  of  J=  CM — a 
rule  of  inference  known  to  logicians  as  the  Necessitation  Rule.  This  rule 
implies  that  whenever  we  give  a  predicate  P  as  a  temporal-logic  axiom,  we 
are  really  asserting  that  □  P  is  true. 

The  validity  of  the  Necessitation  Rule  means  that  it  is  impossible  to  write 
a  temporal  logic  formula  which  asserts  that  the  program  is  executed  only 
in  certain  starting  states.  Thus,  one  should  define  the  semantics  jMJSJ  of  S 
to  consist  of  both  a  set  of  temporal  logic  axioms  that  constrain  the  allowed 
behaviors  of  S  and  a  set  of  nontemporal  axioms — that  is,  predicates — that 
constrain  the  starting  state.  The  semantic  meaning  MJ5J  defines  the  set  of 
behaviors  of  5  to  be  the  set  of  all  behaviors  <7  such  that: 

•  a  A  for  every  temporal  axiom  A  €  M[S],  and 

•  s0  [=  A  for  every  nontemporal  axiom  A  €  ,M|[Sj,  where  s0  is  the 
starting  state  of  a. 

However,  as  I  will  show,  it  is  not  necessary  to  specify  any  initial  states  for  a 
substatement  S  of  a  program.  The  only  initial-state  specification  that  must 
be  added  is  that  a  complete  program  starts  at  its  entry  point. 

5.6  There  Won’t  Be  a  Next  Time 

An  important  “feature”  of  the  temporal  logic  I  am  using  is  that  there  is  no 
“next  time”  operator.  There  is  no  way  in  this  logic  to  express  the  concept 
of  the  next  state  in  the  behavior.  In  fact,  no  formula  in  the  logic  can  distin¬ 
guish  between  two  behaviors  that  differ  only  in  the  addition  of  “stuttering” 
actions — that  is,  where  an  action  s  -2-»  t  in  the  behavior  is  replaced  by  the 
finite  sequence  of  actions 


5.4  Renaming 

Having  already  extended  the  renaming  mappings  to  predicates,  it  is  easy  to 
extend  them  to  temporal  logic  formulas  constructed  from  predicates.  For 
example,  for  any  variable  names  v  and  w,  we  have 

Cs.-ilOft'VOw))  =  VOcs») 

Thus,  if  T  is  the  substatement  S,  q  of  S, 

Ps,- , :  TL{T)  -  TC(S) 

The  renaming  mappings  do  not  induce  any  mappings  on  behaviors.  This 
is  because  they  map  states  and  atomic-action  names  in  opposite  directions: 

Psn  :  S(S)  -  S(T) 

Ps,-,  :  A(T)  -  J!(S) 

Since  a  behavior  consists  of  an  alternating  sequence  of  states  and  action 
names,  the  renaming  mappings  do  not  work  on  behaviors.  This  may  be 
the  source  of  the  difficulties  encountered  in  trying  to  give  a  behavioral 
semantics — one  in  which  ,M|S]]  is  a  set  of  behaviors — to  concurrent  pro¬ 
gramming  languages 

5.5  Temporal  Logic  as  Semantics 

For  each  statement  S  of  the  programming  language,  I  have  defined  a  set 
7£(S)  of  temporal  logic  formulas,  and  a  notion  of  semantic  validity  f=  for 
these  formulas.  In  an  action-axiom  semantics,  the  meaning  of  S  includes  a 
set  of  temporal  logic  formulas  that  must  be  satisfied  by  the  behaviors  of  S. 
This  set  of  formulas  is  specified  by  giving  axioms  and  inference  rules,  which 
means  that  we  have  a  logical  system  and  a  notion  of  a  provable  formula.  I 
will  not  discuss  provability,  and  will  restrict  myself  to  validity. 

I  have  defined  a  A  for  a  behavior  o  and  a  temporal  logic  formula  A, 
but  1  have  not  defined  the  concept  A — validity  of  a  formula.  For  any 
formula  A  6  T£(S),  one  usually  defines  |=  A  to  equal  true  if  and  only  if 
o  A  equals  true  for  ail  behaviors  o  in  B(S). 

The  formulas  /I  for  which  |=  A  is  true  are  those  that  are  true  for  all 
sequences  of  states  and  actions  from  5,  so  their  truth  rests  only  on  the 
properties  of  S’s  sets  of  states  and  actions,  not  on  properties  of  S”s  dynamic 
behavior— for  example,  the  formula  □  (a:()  €  Z  D  (x2  >  x)).  A  formula  A 
is  said  to  valid  for  all  behaviors  in  some  subset  E  of  S(S),  written  f=v  A,  if 


Intuitively,  A<  B  means  that  B  holds  for  at  least  as  long  as  A  does — that 
is,  A  holds  for  a  length  of  time  <  the  length  of  time  that  B  holds,  so  it 
represents  a  “temporal  <*. 

I  will  extend  the  definition  of  T£(S)  to  include  temporal  formulas  con¬ 
structed  with  the  operator  <  as  well  as  □  and  O-  The  unary  operators  can 
be  defined  in  terms  of  < ;  for  example,  □  A  s  true  <  A.  Thus,  the  single 
operator  <1  is  all  we  need. 

The  operator  <  is  defined  in  terms  of  <  by 

A<  B  =f  (AV^B)  <  B 
A  little  thought  shows  that 

<r  |=  (A  <  B)  =  Vn  :  (Vm  <  n  :  <r+m  f=  A)  D  <r+n  f=  B 

so  A  <  B  means  that  A  holds  for  a  length  of  time  <  the  length  of  time  that 
B  holds.  The  operators  <  and  <  obey  the  same  transitivity  relations  that 
<  and  <  do.  For  example, 

{A<  B)  A  (B  <  C)  D  ( A<C ) 

I  will  use  <  to  define  a  new  type  of  temporal  formula  that  is  useful  for 
specifying  actions.  For  any  action  name  a  6  jl(S)  and  any  predicates  P  and 
Q,  I  define  {P}(a){Q}  to  be  the  temporal  logic  formula  that  means  that 
executing  a  starting  in  a  state  in  which  P  is  true  can  produce  a  state  in 
which  Q  is  true.  (It  is  just  the  ordinary  Hoare  triple  for  the  atomic  action  a, 
viewed  as  a  temporal  formula.)  However,  we  must  allow  stuttering  actions 
of  a  which  do  nothing,  and  hence  leave  P  true.  The  formal  definition  is 

{F}(«){Q}  =f  P  3  Mct(a)  <  PVQ) 

Intuitively,  a  [=  {P}(a){Q}  asserts  that  if,  P  is  true  in  the  initial  state  of 
a  and  the  first  one  or  more  actions  of  a  are  a  actions,  then  PVQ  remains 
true  through  the  first  state  before  the  first  action  that  is  not  an  a  action. 
If  Q  D  -tAct(a)  holds,  which  is  the  only  case  in  which  this  is  formula  will 
be  used,  then  Q  will  be  true  only  after  the  last  of  these  initial  a  actions. 
Hence,  it  asserts  that  a  can  perform  a  series  of  stuttering  actions  leaving  P 
true,  and  can  also  “finish”  by  making  Q  true. 

The  formula  {P}(a){Q}  is  used  to  describe  how  an  action  can  change  the 
state.  It  is  also  necessary  to  state  that  an  action  does  not  change  something. 

a 

I  therefore  introduce  the  formula  e  */-,  which  asserts  that  the  action  a  does 
not  change  the  value  of  the  expression  e.  It  is  defined  by 


“n+1 


<*n+2 


*  ®n+t  ' 

unless  a  is  finite  and  n  is  less  than  the  length  m  of  o,  in  which  case  <r+n 
is  defined  to  be  the  sequence  consisting  of  the  single  state  sm.  We  define 
a  \=  A  inductively  as  follows. 

•  If  A  is  a  state  predicate,  then  a  \ =  A  *==f  so  h  A.  (The  value  of  a 
state  predicate  is  its  value  in  the  starting  state.) 

•  If  A  is  an  action  predicate,  then  a  A  =f  aj  h  A.  (The  value  of  an 
action  predicate  is  its  value  for  the  first  action.)  However,  if  a  consists 

of  the  single  state  so  with  no  actions,  then  a  f=  A  d=  false. 

•  The  logical  connectives  “distribute"  in  the  obvious  way.  For  example, 

a  f=  (A  V  B)  d=  (<r  |=  A)  V  (<y  f=  B) 

•  The  temporal  operators  are  defined  by 

o)=  DA  d=  Vn:<r+fl  (=  A 
a  h  A=  3”  :  h  A 

Note  that  O  is  the  dual  of  □ — that  is,  CM  =  for  any  A.  The 

operator  is  defined  by 

A^B  =f  Q(ADOB) 

Note  also  that  ClO-4  has  the  intuitive  meaning  that  A  is  true  infinitely 
often. 


5.3  The  Binary  Temporal  Operators 

While  the  unary  temporal  operator  □ .  and  the  operators  derivable  from 
it,  are  quite  natural  and  easy  to  understand,  they  are  not  sufficiently  ex¬ 
pressive.  We  need  an  additional  binary  temporal  operator.  There  are  many 
binary  operators  that  are  equivalent  in  the  sense  that  one  can  be  represented 
by  another.  My  favorite  one,  introduced  in  (6],  is  the  operator  <,  whose 
semantics  is  defined  as  follows. 

o  h  (.4  <  B )  =f  Vn  :  (Vm  <  n  :  a+m  )=  .4)  D  er+n  f=  B 
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is  a  predicate  containing  the  free  logical  value  variable  x,  the  bound  logical 
value  variable  q,  and  the  two  program  variables  x()  and  y(5,  7)  in  V(5). 
For  any  predicate  P  and  state  s  of  S(S),  s  [=  P  is  a  formula  involving  values 
and  value  variables. 

An  action  predicate  of  S  is  an  expression  of  the  form  Act(S,  7),  where 
5, 1 <  is  a  substatement  of  5.  The  action  predicate  Act(S,  7)  defines  a  boolean¬ 
valued  function  on  the  set  ^(5)  that  has  the  value  true  on  an  action-name 
a  if  and  only  if  a  is  the  name  of  an  atomic  action  of  the  substatement  5,  7. 
I  write  a  f=  Act(5, 7)  to  denote  the  value  of  Act(S,  7)  on  a.  Remembering 
that  atomic-action  names  are  just  components  S,/i  of  5,  we  see  that  5,/z  |= 
Act(S,  7)  equals  true  if  and  only  if  /1  =  7,  v  for  some  v. 

Let  PP(S)  denote  the  set  of  all  state  and  action  predicates  of  5.  Since 
state  predicates  are  built  out  of  variable  names  and  action  predicates  are  all 
of  the  form  Act(S,  7),  the  renaming  mappings  induce  mappings  on  predicates 
in  the  obvious  way.  If  T  is  the  substatement  5,  7  of  5,  then 

fis.y  :  PR{T)  -  PR(S) 

These  renaming  mappings  satisfy  the  expected  relation  (2).  Moreover,  if  P 
is  a  tautotology  of  PZ(T),  then  ps,i  is  a  tautology  of  PR(S). 


5.2  The  Unary  Temporal  Operators 

I  will  begin  with  the  simpler  form  of  temporal  logic,  using  only  unary  tem¬ 
poral  operators.  The  formulas  of  this  logic  are  constructed  from  predicates, 
the  usual  logical  operations,  and  the  two  unary  temporal  operators  O  and 
□ .  More  precisely,  for  any  statement  5,  the  set  TC(S)  of  temporal  logic  for¬ 
mulas  of  5  consists  of  all  formulas  constructed  from  PR.(S)  with  the  logical 
operators  and  the  unary  operators  O  and  □ . 

Just  as  predicates  are  true  or  false  for  states,  temporal  logic  formulas  are 
true  or  false  for  behaviors.  Let  5(5)  denote  the  set  of  all  finite  and  infinite 
sequences  of  the  form 

a  I  a* 

So  - *  $1  — -  •  *  * 

where  the  a,-  are  states  in  S(5)  and  the  a are  atomic-action  names  in  >1(5). 
We  give  a  semantics  for  temporal  logic  formulas  by  defining  a  \=  A  for  any 
behavior  a  in  5(5)  and  any  temporal  logic  formula  A  in  7£(5). 

If  a  is  the  sequence  (5),  for  any  nonnegative  integer  n  let  (T+n  be  the 
sequence 


5  Temporal  Logic 

In  the  action-axiom  semantics,  I  use  temporal  logic  to  express  the  con¬ 
straints  describing  when  an  action  must  eventually  occur.  Temporal  logic, 
introduced  into  the  study  of  concurrent  programs  by  Pnueli  [13],  is  now 
quite  familiar.  I  will  therefore  only  sketch  the  logic  that  I  will  need,  and 
refer  the  reader  to  [5]  and  the  appendix  of  [6]  for  more  details. 

5.1  Predicates 

The  building-blocks  of  our  temporal  logic  are  predicates.  For  any  program 
statement  S,  1  define  a  set  of  predicates.  There  are  two  kinds  of  predicates: 
state  predicates  and  action  predicates. 

A  state  predicate  of  5  is  just  an  expression  constructed  from  variable 
names  in  'V(S),  including  control  variable  names.  For  example, 

at(S,i)  V-.6Q  D  x(S,n)  =  y()  +  1 

I  will  also  include  as  predicates  such  expressions  as  v  €  Z,  where  v  is  a 
variable  name  and  Z  denotes  the  set  of  integers. 

Since  a  state  in  S(S)  assigns  a  value  to  all  variable  names  in  t'(S),  it 
assigns  a  value  to  a  predicate.  For  any  state  s  of  S(S),  I  denote  by  s  |=  P 
the  value  assigned  to  the  state  predicate  P  by  the  state  s. 

A  predicate  is  normally  a  boolean-valued  expression,  but  I  have  not 
restricted  predicates  in  this  way;  y{)  +  17  is  just  as  much  a  predicate  as  -<b(). 
The  reason  is  that  there  is  no  way  of  knowing  whether  an  expression  has  a 
boolean  value  without  knowing  the  types  of  all  its  variables,  and  the  types 
of  undeclared  variables  are  not  known.  We  must  have  rules  for  computing 
the  value  of  y()  +  17  even  when  the  value  of  y()  is  true.  1  will  handle  this 
problem  by  adding  an  additional  undefined  value,  and  define  true  +  17  to 
equal  undefined. 

The  presence  of  an  undefined  value  means  that  we  must  be  careful  when 
manipulating  expressions,  since  the  usual  rules  of  arithmetic  and  logic  don’t 
hold.  For  example,  x+  1  >  x  does  not  equal  true  if  x  is  a  boolean.  However, 
x  6  Z  D  (x  +  1  >  x)  should  always  have  the  value  true. 

It  is  necessary  to  allow  predicates  to  have  logical  value  variables  (not  to 
be  confused  with  program  and  control  variables)  and  quantifiers.  Thus, 


These  renaming  mappings  satisfy  (2)  and  (4) 


» 


B-29 


Since  action  names  are  just  the  names  of  substatements,  the  renaming 
mappings  can  be  applied  to  them  in  the  usual  way.  Thus,  if  T  is  the  sub¬ 
statement  5, 7  of  5,  then 

pSll  :  A(T)  -  A(S) 

is  defined  in  the  obvious  way — namely,  Ps^iT,?)  =  S,~i,p. 

4.6  States  and  Actions:  A  Formal  Summary 

For  every  statement  5  in  the  language  L,  I  have  defined  the  following: 

•  A  set  "V(S)  of  variable  names,  consisting  of: 

-  all  program-variable  names  of  the  form  x()  for  every  identifier  x 
and  of  the  form  x(S,  7),  where  7  is  the  selector  in  5  of  a  new  x 
statement. 

-  all  control-variable  names  of  the  form  at(5, 7),  in(S,  7),  and 
after(S,  7),  for  all  substatements  S,  7  of  S. 

•  The  set  S(S)  of  states  of  S,  which  is  defined  defined  to  be  the  set  of 
all  mappings 

val  :V(S)  -*  Z  U  {true,  false} 

•  The  set  A[S)  of  atomic-action  names  of  5,  defined  to  be  the  set  of  all 
components  of  the  form  S,  7  where  5, 7  is  a  while  or  if  test,  an  atomic 
assignment,  or  an  init  clause  of  a  new  statement. 

•  If  T  is  the  substatement  S,  7  of  S,  the  renaming  mappings 

m:V{T)-V{S) 

_ P's,i :  S(S)  -»  S(T)ps,y  :  A(T)  -  A(S) 

x:=  x 2 

of  program  II,  and  consider  the  42  steps  in  the  machine-language  implementation  jt  of 
II  that  execute  statement  S.  As  mentioned  earlier,  41  of  them  will  be  stuttering  actions 
that  leave  the  value  of  x  unchanged.  Before  the  first  41  steps  have  been  executed,  tt’s 
state  may  no  longer  have  the  information  needed  to  deduce  the  initial  value  of  x.  For 
example,  after  20  steps,  the  state  of  ir  may  show  that  x  will  wind  up  with  the  value 
4,  but  may  not  show  whether  it  started  equal  to  2  or  —2.  This  means  that  the  single 
nonstuttering  action  must  be  among  the  first  20  steps,  and  the  remaining  steps  must 
be  stuttering  actions  of  the  statement  following  S.  If  5  is  the  last  statement  of  II,  then 
these  remaining  steps  are  A  actions. 


As, 7, <5  =  PS, 7  °  PT,S  (2) 

By  taking  this  equality  to  be  a  definition,  we  can  formally  define  psn  for  any 
selector  7  by  defining  it  for  all  primitive  selectors.  This  formal  definition 
should  be  obvious  and  is  omitted. 

Let  T  be  the  substatement  5,  7  of  5.  A  state  val  of  S(S)  is  a  mapping 
from  V(S)  to  values,  and  pstl  is  a  mapping  from  D(T)  to  ^(S).  The  com¬ 
position  val  o  pSrt  is  therefore  a  mapping  from  from  V(T)  to  values,  which 
is  a  state  in  5(T).  Thus,  the  mapping  ps, 7  induces,  a  mapping 

Ps,t  ••  5(5)  -  S(T) 

from  states  of  5  to  states  of  T,  defined  by 


def 


(3) 


PS, y(val)  =  valopSa 
for  any  val  6  S(5).4 

It  follows  easily  from  (2)  that  the  mappings  p*Sl  satisfy  the  following 
“adjoint"  form  of  (2). 

Ps,y,s  =  Pt,s  0  Ps,i  (4) 


4.5  Actions 

The  states  of  S  are  defined  using  the  set  V(S)  of  variable  names.  The 
actions  of  5  will  be  defined  in  terms  of  a  set  A(S)  of  atomic-action  names 
of  5. 

The  atomic  actions  of  5  are  the  components  written  in  angle  brackets. 
In  the  language  L,  there  are  just  four  kinds  of  atomic  actions:  assignment 
statements,  if  tests,  while  tests,  and  init  clauses  (of  new  statements).  (I 
assume  that  the  initial-value  assignment  of  the  new  statement  is  performed 
as  a  single  atomic  action.)  The  set  A(S)  of  atomic-action  names  of  5  consists 
of  the  set  of  all  components  5, 7  of  5  such  that  7  is  a  selector  for  one  of  the 
following:  an  assignment  statement,  the  test  component  of  an  if  statement, 
the  test  component  of  a  while  statement,  or  the  init  component  of  a  new 
statement.  For  reasons  having  to  do  with  defining  compiler  correctness  that 
are  irrelevant  to  the  remainder  of  this  paper,  if  II  is  a  complete  program, 
then  jl(n)  is  defined  to  contain  one  additional  action  name:  the  name  A, 
which  is  the  name  of  a  null  action.5 

4The  renaming  mapping  has  no  connection  with  the  mapping  F  discussed  in  Sec¬ 
tion  2.4.1  between  the  states  of  an  implementation  and  the  states  of  a  higher-level 
program. 

5The  following  example  shows  why  the  A  action  is  needed.  Let  5  be  the  statement 
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It  would  therefore  seem  that  we  should  add  types  and  aliasing  informa¬ 
tion  to  the  state.  In  fact,  we  needn’t.  The  reason  is  that,  in  language  L, 
types  and  aliasing  relations  are  static  properties;  they  do  not  change  during 
execution  of  the  program.  Executing  an  action  of  L  does  not  change  the  type 
of  a  variable  or  any  aliasing  relations.  (We  sometimes  think  of  executing  a 
new  statement  by  first  executing  its  declarations,  but  that  makes  no  sense 
because  declarations  are  not  actions.) 

In  a  more  complex  language,  types  and  aliasing  relations  can  be  dy¬ 
namic.  For  example,  in  Pascal,  if  x  is  a  variable  of  type  pointer,  then  the 
aliasing  relation  “i|  is  aliased  to  y”  is  dynamic,  since  its  truth  is  changed 
by  assigning  a  new  value  to  x.  In  these  cases,  it  may  be  necessary  to  add 
types  and  aliasing  information  to  the  state.  However,  in  most  languages, 
aliasing  relations  among  control  variables  will  be  static,  and  can  be  handled 
the  same  way  as  in  language  L. 

4.4  Renaming 

For  any  statement  S,  let  V(S)  denote  the  set  of  names  of  variables  of  S. 
A  state  val  of  S(S)  is  a  mapping  that'  assigns  a  value  to  each  variable 
name  in  V(S).  For  a  compositional  semantics,  we  must  be  able  to  derive 
information  about  the  states  of  5  from  information  about  the  states  of 
its  component  substatements.  This  requires  the  fundamental  concept  of  a 
renaming  mapping. 

Let  statement  T  be  the  substatement  S, 7  of  5.  Every  variable  of  T  is  a 
variable  of  5,  except  that  it  may  be  known  by  a  different  name.  I  will  define 
Psn  to  be  the  mapping  on  names  such  that  if  v  is  the  name  of  a  variable  in 
T,  then  ps,7(v)  is  the  name  of  the  corresponding  variable  in  S.  Hence, 

Ps,y^(T)-  V(S) 

The  variable  x(T,n),  which  is  the  variable  of  T  with  identifier  x  that  is 
declared  in  the  new  statement  T,p,  is  called  by  the  name  x(S,  7,/i)  when 
it  is  regarded  as  a  variable  of  S.  Thus, 

Ps,7(*(T\/i))  =  x(S,  7,p) 

A  variable  that  has  the  name  x()  as  a  variable  in  T  is  undeclared  in  T. 
If  it  is  undeclared  in  5,  then  it  has  the  same  name  as  a  variable  of  S,  so 
Ps.iM))  =  x().  However,  if  it  is  declared  in  the  new  x  statement  5,  v,  so 
v  is  a  prefix  of  7,  then  p5,7(x())  =  x(S,i/). 

The  renaming  mappings  compose  in  the  natural  way.  If  T  is  the  sub¬ 
statement  5, 7  of  S,  then  for  any  substatement  T  f>  of  T,  we  have 
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I  therefore  prefer  to  use  the  term  implicit  variables  for  variables  other 
than  ordinary  program  variables.  Some  languages  employ  other  implicit 
variables  besides  control  variables.  For  example,  a  language  that  provides 
a  buffered  message-passing  primitive  will  contain  implicit  variables  whose 
values  describe  the  set  of  messages  in  the  queues. 

Ordinary  program  variables  may  be  free  (undeclared),  like  x(),  or  bound 
(declared),  like  x(5, 7).  I  have  written  all  control  variables  as  bound  vari¬ 
ables,  but  are  they  really  bound?  Remember  that  the  free  variables  are 
interface  variables  and  bound  variables  are  internal  ones.  In  order  to  use  a 
compiled  version  of  a  statement  S,  one  must  know  where  its  starting  and 
ending  control  points  are,  but  need  know  nothing  of  its  internal  control 
points.  This  suggests  that  at(S),  in(S),  and  after(S)  are  interface  variables 
for  statement  S,  while,  for  any  non-null  selector  7,  a/(5, 7),  in(S,  7),  and 
after(S,  7)  are  internal  variables.  The  control  variables  at(S),  in (5),  and 
after(S)  are  best  viewed  as  undeclared  and  might  better  be  written  as  at(), 
in{),  and  after().  (They  are  not  written  that  way  both  for  historical  reasons 
and  because  it  would  tend  to  be  confusing.)  These  variables  are  implicitly 
declared,  and  aliased  to  other  control  variables,  when  S  is  written  as  part 
of  a  larger  statement. 

4.3  Are  There  Other  State  Components? 

Does  a  mapping  val  from  variable  names  of  S  values  tell  us  everything  we 
need  to  know  about  the  current  state  of  S  in  order  to  determine  its  future 
behavior?  At  first  glance,  it  might  seem  that  it  doesn’t.  For  example,  what 
is  the  effect  of  executing 

s:  x  :=  y  +  1 

when  the  value  of  y  is  17?  The  answer  depends  upon  the  type  of  x.  If  x  is 
of  type  integer,  then  the  execution  sets  x  to  18.  However,  if  x  is  of  type 
boolean,  then  executing  s  produces  an  error. 

Moreover,  suppose  x  is  of  type  integer  and  y  =  17,  so  executing  s  changes 
the  value  of  x  to  18.  What  does  this  execution  do  to  the  value  of  y?  If  y 
is  not  aliased  to  x,  then  its  value  is  left  unchanged.  However,  if  s  appears 
inside  the  statement 

new  y  :  integer  alias  x  in  . . .  ni 
then  the  value  of  y  is  also  changed  to  18. 
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in(S, 7):  control  is  at  the  beginning  of  or  inside  S,  7,  but  not  at  its  exit 
point.  Note  that  at(S,  7)  D  in(S,  7)  is  always  true. 

after(S,  7):  control  is  at  the  exit  point  of  S,  7 — that  is,  at  the  point  just 
after  its  execution  is  completed. 

In  addition  to  complete  substatements,  the  at,  in,  and  after  variables  are 
also  defined  for  certain  parts  of  statements  that  denote  atomic  operations — 
namely,  the  test  of  an  if  or  while  statement  and  the  init  clause  of  a  new 
statement  (if  it  has  one).  Also,  the  control  variables  af(Il),  »n(n),  and 
after ( II)  are  defined  for  a  complete  program  II. 

The  statement  u  above  thus  has  eight  control  variables:  af(u),  tn(u), 
after(u),  at(s  of  u),  in(s  of  u),  after(s  of  u),  at(t  of  u),  m(t  of  u),  and 
after(t  of  u).  They  are  not  ail  independent,  however,  since  we  have 

at(u)  =  at(s  of  u) 
after(u)  =  after(t  of  u) 

in(u)  =  in(s  of  u)  A  in(t  of  u) 

after(s  of  u)  =  at(t  of  u)  (1) 

These  equations  represent  aliasing  relations  between  the  control  variables. 
The  study  of  these  aliasing  relations  is  deferred  until  later. 

The  mapping  val  that  assigns  values  to  variables  must  assign  values  to 
the  control  variables  as  well  as  the  ordinary  program  variables.  Of  course, 
we  must  assume  that  at,  in,  and  after  are  not  identifiers,  so  they  cannot  be 
used  for  ordinary  program  variables. 

Variables  like  at,  in,  and  after  are  sometimes  called  “dummy”  or  “ghost” 
variables.  This  seems  to  imply  that  they  are  not  as  real  as  ordinary  pro¬ 
gram  variables.  Indeed,  I  have  found  that  many  computer  scientists  regard 
'heir  use  as  somewhat  distasteful — perhaps  even  immoral.  Control  vari¬ 
ables  are  every  bit  as  real  as  ordinary  program  variables.  They  differ  from 
program  variables  only  in  that  the  programmer  does  not  explicitly  write 
them.  Every  programmer  knows  that  he  can  often  simplify  a  program’s 
control  structure — that  is,  eliminate  control  variables — by  adding  program 
variables;  and,  conversely,  he  can  eliminate  program  variables  by  using  a 
more  complex  control  structure — that  is,  by  adding  control  variables.  A 
compiler  handles  both  kinds  of  variables  in  very  much  the  same  way;  in  the 
compiled  version  of  a  program,  the  values  of  program  variables  and  control 
variables  are  both  encoded  in  terms  of  the  contents  of  memory  registers  and 
program-location  counters. 


and  action  names.  The  names  of  interface  variables  and  external  actions 
represent  fixed,  externally  defined  objects. 


6  The  Semantics  of  Language  L 

With  these  preliminaries  out  of  the  way,  I  can  now  give  the  semantics  of 
language  L.  This  is  done  by  defining  the  meaning  MjS]|  of  S,  where  S  is  any 
statement  or  complete  program.  I  define  M|S]  to  consist  of  a  set  of  temporal 
logic  axioms  that  specify  the  set  of  behaviors  of  S.  As  discussed  below,  for 
a  complete  program  II,  I  will  also  need  one  nontemporal  axiom — that  is,  a 
predicate — to  specify  the  starting  state. 

The  basic  idea  behind  achieving  a  compositional  semantics  is  the  re¬ 
quirement  that  any  axiom  asserted  about  a  statement  T  must  be  valid  for 
any  statement  containing  T  as  a  substatement.  Of  course,  an  axiom  about 
T  must  be  renamed  to  become  an  axiom  about  a  statement  containing  T. 
The  formal  statement  of  this  idea  is: 

Composition  Principle:  If  T  is  substatement  S,  7  of  S,  then  for 
any  formula  A:  if  A  €  -M (T'J  then  ps^A  €  -M|S,  7]. 

6.1  Syntactic  Predicates 

I  observed  in  Section  4.3  that  there  is  information  we  need  in  order  to  define 
.MIS]  that  is  not  in  the  state  of  S — namely,  type  and  aliasing  information. 
This  information  is  not  in  the  state  because  it  is  determined  syntactically  and 
does  not  change  during  execution  of  S.  Unfortunately,  it  may  be  determined 
not  by  the  syntax  of  S,  but  by  the  syntax  of  the  complete  program  containing 
S.  For  example,  the  aliasing  relations  defined  by  a  new  statement  are  not 
known  when  defining  MjS]  for  a  statement  S  in  its  body. 

For  our  simple  language  L,  typing  information  can  be  handled  by  ordi¬ 
nary  axioms;  the  fact  that  a  variable  v  is  of  type  integer  is  expressed  by  the 
requirement  that  the  value  of  v  always  be  an  integer.  Aliasing  relations  can 
also  be  expressed  by  similar  requirements — for  example  the  aliasing  relation 
defined  by 

new  z  :  gausian  alias  x  +  y in  ... 

is  expressed  by  requiring  that  the  value  of  z[S)  always  equals  the  value  of 
x{)  +  y()\/-T.  However,  the  fact  that  z(S)  is  not  aliased  to  the  variable  a() 
cannot  be  expressed  in  this  way. 

The  absence  of  aliasing  relations  is  expressed  with  a  new  relation  ±, 
where  v  ±  w  means  intuitively  that  assigning  a  value  to  the  variable  named 
v  does  not  change  the  value  of  the  variable  named  w,  and  vice-versa.  An 
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ordinary  state  predicate  such  a s  v  =  w,  which  asserts  that  the  values  of  v 
and  w  are  equal,  is  true  or  false  for  a  particular  state.  However,  the  truth 
of  the  expression  v  ±  w  depends  only  upon  the  syntactic  structure  of  the 
program;  it  is  true  for  one  state  of  S  if  and  only  if  it  is  true  for  all  states  of 
5. 

An  expression  like  v  ±  w,  whose  value  is  a  boolean  that  depends  only 
on  the  program  syntax,  is  called  a  syntactic  predicate.  Unfortunately,  if  v 
and  u>  are  undeclared  variables  of  5,  then  the  value  oi  v  ±  w  depends  upon 
the  syntax  of  the  program  that  contains  5,  and  its  value  is  not  determined 
when  we  are  defining  A(|5J.  Thus,  a  syntactic  predicate  either  has  a  definite 
boolean  value,  or  else  has  an  undetermined  value. 

I  will  allow  syntactic  predicates  to  appear  in  a  temporal  logic  formula 
of  7£(5)  anywhere  that  an  ordinary  state  predicate  can.  However,  there  is 
no  reason  to  write  <>(v  -t-  w),  since  if  v  J.  to  is  ever  true,  then  it  is  always 
true  for  every  state  of  5.  Formally,  a  syntactic  predicate  in  a  temporal  logic 
formula  of  TC(S)  is  viewed  as  a  boolean  constant  if  its  value  is  determined 
by  5 ,  and  as  a  logical  variable  if  its  value  is  undetermined. 

Formally,  a  syntactic  predicate  appearing  in  an  axiom  of  is  a  con¬ 
stant  if  its  value  is  determined  by  5,  and  it  is  a  logical  variable  if  its  value  is 
not  determined.  Thus,  writing  the  syntactic  predicate  x(S,  7)  ±  y(S,p)  is 
simply  an  “abbreviation”  for  either  true  or  false,  since  the  aliasing  relations 
of  variables  declared  in  S  are  determined.  On  the  other  hand,  a  syntactic 
predicate  such  as  z()  JL  y()  represents  a  logical  variable,  since  aliasing  rela¬ 
tions  between  undeclared  variables  are  undetermined.  Because  there  is  an 
implicit  universal  quantification  over  all  free  logical  variables  in  an  axiom, 
an  axiom  containing  a  syntactic  predicate  is  asserted  to  be  true  whatever 
value  is  assigned  to  it. 

We  can  apply  renaming  mappings  to  syntactic  predicates  in  the  obvious 
way.  Thus,  if  P  is  a  syntactic  predicate  for  T,  and  T  is  the  substatement 
5,7  of  5,  then  Ps.i{P)  is  a  syntactic  predicate  for  S.  When  the  predicate 
P  occurs  in  an  axiom  A  of  •M(7’|,  the  expression  ps^{P)  occurs  in 
which,  by  the  Composition  Principle,  is  an  axiom  of  M|S|.  A  little  thought 
reveals  that,  to  ensure  the  validity  of  the  Composition  Principle,  we  want 
the  following  property  to  hold: 

Syntactic  Composition  Property:  For  any  syntactic  predicate  P: 
if  the  value  of  P  is  defined  for  T,  then  the  value  of  ps.-,(P)  is 
also  defined  for  5  and  equals  the  value  of  P. 

The  use  of  syntactic  predicates  is  not  really  necessary.  1  could  include 


the  information  that  they  express  in  the  state.  Had  I  done  so,  a  syntactic 
predicate  having  an  undetermined  value  would  become  a  component  of  the 
state,  and  S(S)  would  include  states  having  all  possible  values  of  that  pred¬ 
icate.  A  syntactic  predicate  whose  value  is  determined  in  a  statement  S 
could  be  represented  either  as  a  state  component  constrained  to  have  only 
one  possible  value,  or  as  a  constant. 

6.1.1  Aliasing 

The  absence  of  aliasing  will  be  expressed  by  the  relation  _L  between  variable 
names  in  "V  (5).  This  will  be  done  axiomatically  by  defining  a  logical  system 
for  deriving  ±  relations  To  do  this,  I  must  first  introduce  a  relation  -<, 
where  v  -<  {wj, . . . ,wn}  means  that  the  variable  name  v  is  not  directly 
aliased  to  any  variable  names  other  than  It  is  convenient  to 

extend  this  relation  to  a  relation  between  sets  of  variable  names,  where 
{t>i, . . . ,  tVn}  -<  means  that  each  of  the  variable  names  v;  is  not 

directly  aliased  to  any  variable  names  other  than  the  wj.  We  then  have  the 
obvious  inference  rule: 

For  any  sets  V,W  €  ^(S):  if  V'  C  V,  W  C  W',  and  V  <  W, 
then  V'  <  W'. 

The  relation  JL  on  "^(S)  is  defined  so  that  v  _L  w  means  that  neither  v 
nor  w  is  aliased,  directly  or  indirectly,  to  the  other.  In  other  words,  it  means 
that  v  ^  w  and  there  do  not  exist  both  a  chain  of  -<  relations  from  t;  and 
a  chain  of  <  relations  from  w  that  lead  to  a  common  variable  name.  This 
leads  to  the  following  rules  for  deriving  ±  relations. 

•  If  v  -<  0,  w  -<  0,  and  v  ^  w,  then  v  ±  w. 

•  If  v  -L  w  then  w  JL  v. 

•  It  v  <  {ii/j,.  ..,vn},wi  lv,...,uinlv,  and  v  ^  w,  then  t;  _L  w. 

I  extend  1  to  a  relation  on  finite  sets  by  letting  {vi, . . . ,  v„}  i.  {wj, . . . ,  wn) 
denote  V«,j  :  v,-  ±  wj. 

Having  given  general  rules  for  reasoning  about  -<,  I  must  define  the 
relation  for  variables  names  in  S(S)  for  an  arbitrary  statement  5.  The  value 
of  a  syntactic  predicate  V  <  W  or  V  _L  W  will  be  undetermined  if  V  and  W 
both  contain  the  names  of  undeclared  variables  of  5.  To  define  the  values  of 
the  ones  that  are  determined,  I  will  take  the  Syntactic  Composition  Property 
as  an  axiom,  and  give  a  recursive  definition  based  upon  the  structure  of  5. 
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The  first  observation  is  that  a  program  variable  cannot  be  aliased  to  a 
control  variable,  and  vice-versa.  I  therefore  require  that  v  ±  w  equal  true 
whenever  v  is  a  program  variable  and  w  is  a  control  variable. 

Since  the  only  dependency  relations  on  program  variables  are  introduced 
by  the  alias  clauses  of  new  statements,  all  dependency  relations  among 
program  variables  are  obtained  from  the  Syntactic  Composition  Property 
and  the  following  axiom: 

If  5  is  the  statement  new  x  ...  alias  exp  . . .  and  yi,  . . .,  yn  are 
all  the  variable  names  in  exp,  then  x{S)  <  {yi(),  •  •  • ,  yn()}- 

I  must  now  define  the  dependency  relations  on  control  variable  names.  I 
will  do  this  by  assuming  the  Syntactic  Composition  Property  and  defining 
the  relations  introduced  by  each  language  construct.  There  are  a  number  of 
aliasing  relations  that  are  similar  to  the  ones  introduced  by  an  alias  clause, 
except  that  the  aliasing  relations  for  the  control  variables  are  implicit  in 
the  program  structure  rather  stated  explicitly  in  a  new  statement.  To 
define  the  -<  relations,  I  will  write  down  these  aliasing  equations,  where  the 
control  variable  comprising  the  left-hand  side  of  an  equation  is  considered 
to  depend  upon  each  of  the  variables  on  the  right-hand  side.  There  is  one 
set  of  equations  for  each  programming  language  construct. 

Besides  these  aliasing  equalities,  some  other  aliasing  relations  are  given 
as  boolean  expressions — that  is,  asserting  that  the  boolean  expressions  are 
true.  No  dependency  relations  are  implied  by  these  expressions,  but  they 
are  listed  here  for  future  reference. 

There  is  only  one  axiom  that  explicitly  defines  X  relations;  it  is  given 
for  the  cobegin  statement. 

assignment  in(S)  =  at(S) 

-i (at{S)  A  after(S)) 

if  «n(S,  test )  =  at(S,  test) 

after[S,  test)  =  at[S,  then)  V  at(S,  else) 
at(S)  =  af(S,  test) 

in(S )  =  i n(S,  test)  V  in(S,  then)  V  »n(S,  else) 

after(S)  =  after(S,  then )  V  after(S,  else) 

->  (af(S,  feat)  A  ( in(S,then )  V  in(S,else)  V  after(S))) 

-<(in(S,  then)  A  in(S,  else)) 
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while 


at(S) 
in(S,  test) 
after(S,  test) 
after(S,  body) 
in(S) 

-i  ( at(S ,  test) 


=  at(S,  test ) 

=  at(S,  test) 

=  at(S,  body)  V  after(S) 

=  at(S,  test) 

=  at(S,  test)  V  in(S,  body) 
A  (after(S)  V  in(S ,  body))) 


new  There  are  two  cases.  If  there  is  no  init  clause,  then: 


af(S)  =  at(S,  body) 
after(S)  =  after{S,  body) 
in (5)  =  in(S,  body) 

If  there  is  an  init  clause,  then: 

af(S)  =  at(S,  inti) 
in(S,$nit)  —  at(S,init) 
after(S ,  init)  =  at(S,body) 

in(S)  =  in(5,  init)  V  m(5,  body) 
after(S)  =  after(S ,  body) 

-i(at(5,  init)  A  in(S,  body)) 


cobegin  If  there  are  n  clauses  in  the  cobegin,  then 

at(5)  =  at(S,  1)  A  ...  A  al(S,n) 
after(S)  =  after(S,  1)  A  . . .  A  after(S,  n) 
in(S)  =  «n(S,  1)  A  . . .  A  m(5,  n) 
(in(5,i),  after(S,i)}  1  {in{S,j),  after(S,j)}  for  »'  ^  j 

sequence  If  5  is  5j;  ...  Sn,  then  for  all  *  =  1, . . . ,  n: 

after(S,  i  —  1)  =  at(S,i)  if  i  >  0 
in(5)  =  in(S,i) 

->(in(S, i)  A  i'n(5,j))  for  i  ^  j 


program  If  S  is  the  complete  program,  then 


at(5)  =  at(S,body) 
in(S)  =  «n(5,  body) 
after (S)  =  after(S,  body) 


B-43 


A  close  study  of  these  aliasing  relations  reveals  that  we  can  prove  a 
relation  such  as  in(S,~i)  _L  at(S,fi)  if  and  only  if  the  substatements  S,7  and 
S,fi  lie  in  different  clauses  of  a  cobegin. 

The  ±  relations  among  program  variables  and  the  aliasing  and  _L  rela¬ 
tions  among  control  variables  are  regarded  as  axioms  in  a  separate  system 
for  reasoning  about  syntactic  expressions.  However,  they  play  the  same 
function  as  axioms  of  M[5j.  For  example,  if  5,7  is  an  assignment  state¬ 
ment,  then  the  aliasing  relation  -i(at(5,7)  A  after(S,  7))  allows  us  to  deduce 
7))  from  <>after(S, 7). 

6.1.2  Syntactic  Typing  Relations 

Because  the  type  structure  of  our  language  L  is  so  simple,  no  explicit  ref¬ 
erence  to  types  need  appear  in  its  semantics.  However,  this  is  not  the  case 
for  a  language  in  which  the  action  of  an  assignment  statement  is  affected 
by  the  types  of  its  left-  and  right-hand  sides — for  example,  if  coercion  was 
performed.  We  would  also  have  to  introduce  explicit  reference  to  types  if  a 
type  mismatch  in  an  assignment  statement  produced  a  run-time  error  or  an 
indeterminate  result,  or  if  it  halted  the  process  executing  the  assignment. 

Explicit  reference  to  types  is  done  by  introducing  predicates  such  as 
type(x)  —  integer.  If  the  types  of  variables  are  determined  syntactically 
by  the  program  text,  then  these  predicates  would  be  syntactic  predicates. 
Otherwise,  they  would  have  to  be  ordinary  state  predicates,  and  the  state 
would  have  to  include  components  that  determine  their  values. 

6.1.3  Reasoning  About  Syntactic  Expressions 

Although  a  syntactic  predicate  like  t;  ±  w  resembles  an  ordinary  state  predi¬ 
cate  like  v  =  7,  it  is  logically  quite  different.  The  variable  name  “v*  denotes 
the  value  of  the  variable  in  the  expression  v  =  7,  while  it  denotes  the  name 
itself  in  v  ±  w.  For  example,  from  the  expressions  v  =  7  and  u>  =  v  we 
can  deduce  w  =  7.  However,  from  the  syntactic  expression  u  ±  v  and  the 
ordinary  expression  w  =  v  we  cannot  in  general  deduce  u  _L  w,  just  because 
the  values  of  two  variables  happen  to  be  equal  in  some  state  does  not  im¬ 
ply  that  the  variables  have  the  same  aliasing  relations.  We  can  only  make 
that  conclusion  if  w  =  v  is  a  syntactic  equality  of  names,  rather  than  an 
expression  denoting  equality  of  values. 

By  introducing  syntactic  predicates  as  a  class  of  entities  separate  from 
ordinary  state  predicates,  with  their  own  logical  system  for  reasoning  about 
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them,  I  have  circumvented  the  need  to  distinguish  between  the  use  of  a 
variable  name  as  a  name  and  as  a  value.  In  a  syntactic  predicate,  a  variable 
name  represents  itself.  In  a  state  predicate,  it  represents  the  value  of  the 
variable.  Using  two  different  logical  systems  avoids  confusion.  One  cannot 
make  invalid  deductions,  like  deducing  a  J.  relation  from  the  equality  of  the 
values  of  v  and  w,  because  inferences  about  _L  can  be  made  only  in  the  logic 
for  reasoning  about  syntactic  predicates,  whereas  equality  of  values  can  be 
expressed  only  with  state  predicates,  and  one  reasons  about  them  with  a 
separate  logic. 

For  languages  in  which  types  and  aliasing  relations  are  dynamic  prop¬ 
erties,  so  they  must  be  reflected  in  the  state,  we  cannot  use  this  trick  for 
separating  the  two  different  uses  of  variable  names.  We  must  then  write 
value(v)  rather  than  the  variable  name  v  to  denote  the  value  of  v.  Equal¬ 
ity  of  values  is  denoted  by  the  predicate  value(w)  =  value(v),  and  w  =  v 
denotes  equality  of  names. 

6.1.4  Logical  Name  Variables 

Just  as  I  introduced  logical  value  variables  in  state  predicates,  I  will  also 
introduce  logical  name  variables  for  syntactic  predicates.  A  logical  value 
variable  is  a  logical  variable  with  an  implicit  range  in  the  set  of  values  that 
a  variable  may  have.  Similarly,  a  logical  name  variable  is  a  logical  variable 
with  an  implicit  range  in  the  set  of  names  that  a  variable  may  have.  I  will 
use  the  letter  v  to  denote  a  logical  name  variable. 

The  use  of  logical  name  variables  has  an  important  implication  with  re¬ 
spect  to  renaming.  Consider  an  axiom  of  the  form  Vi/  :  A[v).  Viewed  as 
a  formula  in  T£(S),  it  is  equivalent  to  an  infinite  conjunction  of  the  form 
A(i’i)  A  A(v 2)  A  where  the  v,-  are  all  the  names  in  V(S).  However,  the 
two  formulas  behave  differently  under  a  renaming  mapping  p.  In  particu¬ 
lar,  p(Vv  :  A(v))  equals  Vj/  :  p(A(i/)),  so  the  renamed  formula  includes  a 
quantification  over  variable  names  not  present  in  p{A(vi)  A  •••). 

6.2  Starting  States 

One  might  expect  that  the  meaning  M|[5j  of  a  statement  S  should  include 
a  set  of  axioms  that  determine  the  set  of  starting  states.  However,  consider 
what  the  initial  value  of  a  program  variable  should  be.  The  user  has  no  way 
of  specifying  it,  since  an  init  clause  of  a  new  statement  is  interpreted  as  an 
executable  action  that  replaces  the  initial  value  with  the  specified  one.  One 
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might  want  to  specify  that  the  initial  value  of  a  variable  v  of  type  integer 
should  be  an  integer.  However,  .MfS]  will  contain  an  axiom  asserting  that 
this  is  true  for  every  state  during  the  execution  of  S,  so  it  is  therefore  true  of 
the  initial  state.  Similarly,  the  axioms  in  M([S]  will  assert  that  the  aliasing 
relations  specified  by  new  statements  are  true  throughout  the  execution,  so 
they  are  also  constrained  to  hold  in  the  initial  state. 

What  about  the  initial  values  of  control  variables?  Surely  we  should 
require  that  a  statement  S  should  start  in  a  state  in  which  at(S)  is  true. 
However,  this  would  be  a  mistake  because  it  would  violate  the  Composition 
Principle,  since  Pt-,s, 2iat(^))  should  not  be  true  of  the  starting  state  of  the 
sequence  of  statements  T;$,  and  our  whole  approach  is  based  upon  the 
Composition  Principle. 

Remember  that  the  only  reason  for  specifying  the  starting  state  is  to 
be  able  to  obtain  from  our  semantics  a  set  of  behaviors.  However,  we  are 
really  interested  only  in  the  set  of  behaviors  of  a  complete  program,  not 
of  its  substatements.  There  is  no  reason  to  constrain  the  starting  states 
of  substatements;  we  need  only  constrain  the  starting  state  of  a  complete 
program,  which  we  do  by  simply  assuming  that  at(n)  is  true  of  the  initial 
state  of  a  complete  program  n.  We  can  do  this  without  violating  the  Com¬ 
position  Principle  because  a  complete  program  cannot  be  part  of  any  larger 
statement. 

6.3  Behavior  Axioms 

I  now  define  the  set  ,M[S]  of  behavioral  axioms  for  any  statement  and  com¬ 
plete  program  5.  This  will,  of  course,  be  done  compositionally,  giving  a 
set  axioms  for  each  language  construct.  Remember  that  in  addition  to  the 
axioms  given  explicitly  below,  ,M[S]  also  contains  all  the  axioms  implied  by 
the  Composition  Principle. 

I  will  include  in  MJ5J  axioms  to  assert  that  the  appropriate  aliasing 
relations  hold  throughout  the  execution  of  5.  For  control  variables,  those 
aliasing  relations  were  already  described  in  Section  6.1.1.  Rather  than  write 
them  over  again,  I  will  simply  assume  that  the  aliasing  relations  described 
there  appear  as  axioms  in  .MflSj  for  the  appropriate  construct  describing  5. 
For  example,  the  list  of  axioms  for  the  assignment  given  below  are  assumed 
implicitly  to  include  the  axioms  in(5)  =  at{S)  and  ->at(S)  A  after(S)  from 
Section  6.1.1.  (However,  the  ±  relations  given  for  the  cobegin,  being  syn¬ 
tactic  predicates,  are  not  axioms  in  M|S].) 

In  addition  to  the  aliasing  relations  for  control  variables,  we  should  also 


assert  their  types.  Therefore,  we  implicitly  add  the  axiom  v  €  {true, false} 
to  for  every  control  variable  v  in  V(S). 

There  are  also  axioms  relating  the  action  predicate  Acf(S)  to  the  action 
predicates  of  its  components.  For  example,  the  axioms  for  a  while  statement 
5  would  include  the  following: 

•  Act(S)  s  Act(S,  test)  V  Act(S,body) 

•  -<(Act(S,  test)  A  Act(S,  body)) 

The  first  asserts  that  the  only  actions  of  S  are  the  test  action  and  the 
actions  of  its  body;  the  second  asserts  that  the  test  action  is  not  an  action 
of  the  body.  These  and  similar  axioms  are  assumed  for  all  the  constructs 
and  are  not  included.  Note  that  these  axioms  are  given  only  for  compound 
statements;  there  is  no  such  axiom  for  the  assignment  statement. 

In  the  following  description  of  the  axioms,  formal  axioms  are  followed 
by  their  informal  explanations.  For  any  programming-language  expression 
exp,  I  let  cxp{)  denote  the  expression  obtained  by  replacing  every  identifier 
y  in  exp  by  the  variable  name  y(). 

6.3.1  Assignment 

If  5  is  the  statement  {x  :=  exp),  then  contains  the  following  axioms: 

1.  ,4ct(5)  D  at(S) 

The  atomic  statement  5  can  be  executed  only  when  control  is  at  5. 

2.  Vrj  :  (af(S)  A  exp()  —  q}{S){after(S)  A  x()  =  rj) 

Executing  S  sets  the  value  of  x  to  exp  and  changes  control  from  af(S) 
to  after(S). 

3.  Vj/  :  {x(),  at(5),  after(S)}  ±  v  D  v  <~f- 

(Note  that  v  is  a  logical  name  variable.)  The  statement  S  does  not 
modify  any  variable  not  aliased  to  x,  at(S),  or  after(S). 

4.  aOAct(S)  D  O^at(S) 

There  cannot  be  infinitely  many  actions  of  5  while  control  remains 
forever  at  5.  (The  reader  may  find  this  easier  to  understand  if  he 
replaces  the  implication  by  a  disjunction.)  In  other  words,  there  can 
be  only  finitely  many  stuttering  actions  of  5  before  the  assignment  is 
executed. 


An  understanding  of  these  axioms  for  assignment  is  crucial  to  an  ap¬ 
preciation  of  how  action-axiom  semantics  works,  so  some  further  discussion 
of  them  is  in  order.  The  four  axioms  are  indeed  action  axioms,  since  they 
describe  the  behavior  of  the  assignment  action  S.  The  four  axioms  assert 
the  following: 

1.  When  the  action  may  occur. 

2.  What  changes  to  the  state  components  executing  the  action  may  per¬ 
form. 

3.  What  state  components  the  action  may  not  change. 

4.  When  the  action  must  change  the  state. 

Every  atomic  program  action  is  described  by  four  similar  axioms. 

Note  that  axioms  1-3  assert  safety  properties,  while  axiom  4  states  a 
liveness  property.  From  the  axioms  for  the  other  statements,  it  will  follow 
that  in  language  L,  if  at(S)  ever  becomes  true,  it  can  be  made  false  only 
by  executing  action  S.  Axiom  2  asserts  that  at(S)  can  then  become  false 
only  when  after(S)  becomes  true  and  the  assignment  of  exp  to  x  occurs. 
In  a  richer  language,  executing  another  statement  might  make  at(S)  be¬ 
come  false — for  example,  by  aborting  the  process  containing  statement  S. 
However,  Axioms  1-4  would  still  be  valid. 

Observe  that  Axiom  2  determines  the  value  of  z  immediately  after  exe¬ 
cution  of  S.  However,  it  asserts  nothing  about  z’s  value  after  the  execution 
of  any  other  action. 

For  language  L,  Axiom  4  implies  that  if  at(S)  is  true  then  eventually 
it  will  become  false  (thereby  making  after(S)  true).  However,  this  depends 
upon  the  fact  that  that  L  does  not  have  any  form  of  unfair  cobegin.  The 
axiom  is  valid  for  more  general  languages  that  do  have  these  features. 

It  is  instructive  to  consider  what  these  axioms  imply  in  case  statement  S 
appears  inside  declarations  that  produce  a  type  mismatch — say  in  which  z  is 
of  type  integer  and  exp  of  type  boolean.  The  axioms  for  those  declarations 
will  imply  that  the  value  of  z  is  always  an  integer  and  the  value  of  exp  is 
always  a  boolean.  It  then  follows  from  Axiom  2  that  executing  an  5  action 
can  never  make  at(S)  false,  since  doing  so  would  require  setting  the  value 
of  z  to  a  boolean,  contradicting  the  axioms  for  the  declarations.  However,  I 
have  already  observed  that,  for  language  L,  at(S)  must  eventually  become 
false.  Thus,  the  set  of  axioms  for  the  incorrect  program — the  one  producing 
a  type  mismatch  in  statement  5 — are  contradictory,  implying  that  only 
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ft 

the  empty  set  of  behaviors  satisfy  them.  However,  in  a  richer  language,  •; 

if  5  were  contained  inside  an  unfair  cobegin,  then  the  axioms  might  not 
be  contradictory,  and  might  be  satisfied  by  a  behavior  in  which  a  process 

remained  stalled  forever  with  af(S)  true.  In  this  case,  the  type  mismatch  ^ 

would  force  that  process  to  “die”,  allowing  other  processes  to  proceed. 

6.3.2  The  if  Statement 

If  5  is  the  statement  if  (exp)  then  ...  ,  then  the  following  axioms  are  in 

.M[S].  They  are  the  standard  four  action  axioms — in  this  case,  for  the  test  ft 

action.  Note  their  similarity  to  the  corresponding  axioms  for  the  assignment 

statement. 

1.  Act(S,test)  D  at(S,  test) 

The  test  can  be  executed  only  when  control  resides  at  it.  ^ 

2.  {af(S,  test)}(S,  test){[at(S,  then)  A  expQJ  V  (at(5,  e/se)  A -ieip()]} 

Control  remains  at  the  beginning  of  the  test  until  it  either  reaches  the 
entry  point  of  the  then  clause  with  exp  true,  or  else  it  reaches  the 
entry  point  of  the  else  clause  with  exp  false. 

S,teit  * 

3.  Vi /:  [at(S,  test),  after (S,  test)}  ±  1/  D  v  */■ 

The  test  does  not  modify  any  variable  it  shouldn’t.  (Again,  v  is  a 
logical  name  variable.) 

•4.  OOActfS,  test)  D  0~<ot(S,  test)  |‘ 

There  can  be  only  finitely  many  stuttering  actions  of  the  test  before  it 
is  really  executed.  This  is  the  only  liveness  axiom  for  the  if  statement. 

6.3.3  The  while  Statement 

The  axioms  for  the  statement  while  ( exp )  do  ...  are  analogous  to  the  ones  * 

for  the  if  statement,  and  are  given  without  comment. 

1.  Act(S,  test)  D  at(S,te3t) 

2.  {at(S,  test)} (S,  test) {(at(S,  body)  A  expQ)  V  (a/ier(5)  A -'eip())} 

ft 

S,teit 

3.  Vt f :  {at(S,  test),  after(S,  test)}  ±  v  D  v  */■ 

4.  a<>Acf(S,  test)  D  O -<at(S,test) 

» 
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6.3.4  The  new  Statement 

The  new  statement  is  a  declaration.  If  it  has  no  init  clause,  then  it  performs 
no  new  action.  The  axioms  describing  this  statement  therefore  do  not  follow 
the  pattern  for  action  axioms  followed  by  the  preceding  statements.  Instead, 
they  assert  relations  that  hold  throughout  the  execution. 

If  S  is  the  statement 

new  x  :  type  in  . . . 

then  the  following  axiom  is  in  .MlS],  where  we  identify  integer  with  the  set 
Z  and  boolean  with  the  set  {true, false}. 

1.  x(5)  G  type 

The  value  of  x  is  always  consistent  with  the  type  declaration. 

If  5  is  the  statement 

new  x  :  type  alias  exp  in  . . . 
then  contains  the  above  axiom  plus  the  following: 

2.  x(S)  =  exp{) 

The  aliasing  relation  always  holds. 

If  5  is  the  statement 

new  x  :  type  init  exp  in  . . . 

then  the  following  axioms  hold.  The  first  is,  of  course,  the  same  as  for  the 
other  versions  of  the  new  statement.  The  last  four  are  the  action  axioms 
for  the  initial-assignment  action,  following  the  standard  pattern.  They  are 
almost  identical  to  the  corresponding  axioms  for  the  assignment  statement, 
the  only  difference  (in  axiom  3  below)  indicating  that  the  init  clause  per¬ 
forms  an  assignment  to  the  variable  x(S)  declared  in  the  new  statement 
rather  than  to  the  undeclared  variable  z(). 

1.  x(S)  €  type 

2.  Act(S,  init)  D  at(S,init) 

3.  Vrj  :  {at(S,  init)  A  exp()  =  r]}(S){after(S,  init)  A  x(S)  =  r;} 

S.init 

4.  Vt>  :  (x(S),  af(5),  after(S)}  ±  v  D  v 

5.  □O-'teffS,  »n»f)  3  *n«() 
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6.3.5  The  cobegin  Statement 
If  5  is  the  statement 

.  cobegin  Sj  Q  . . .  □  SB  coend 

then  the  following  axiom  is  in  M|5J. 

1.  Vi  s.t.  1  <  *  <  n  :  (D<Mct(S))  D  (□<> Act(S,i)) 

If  S  performs  infinitely  many  actions,  then  each  process  of  S  performs 
infinitely  many  actions.  In  other  words,  if  S  is  never  starved,  then  no 
subprocess  of  5  is  starved.  This  is  the  fairness  axiom. 

6.3.6  Sequences  of  Statements 

No  new  axioms  are  needed  for  the  sequence  of  statements  Si;  ...  ;  Sn.  AH 
necessary  properties  are  obtained  from  the  aliasing  relations  among  its  con¬ 
trol  variables,  the  relations  among  its  action  predicates,  and  the  Composition 
Principle. 

6.3.7  A  Complete  Program 

If  II  is  a  complete  program,  then  the  only  additional  axiom  in  Mjnj  is: 

1.  «n(n)  D  Act(U,  body) 

The  complete  program  never  stops  executing  until  it  reaches  the  end, 
whereupon  m(II)  becomes  false. 

This  axiom  asserts  the  absence  of  any  external  actions  while  control  is  in 
progam  n,  reflecting  the  absence  of  any  explicit  input  or  output  in  language 
L. 
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from  the  axioms  for  the  corresponding  construct  given  here  in  Section  6.3, 
together  with  the  Composition  Principle. 

As  described  in  [9],  other  logical  systems  for  proving  safety  properties  of 
concurrent  programs  can  be  described  in  terms  of  GHL,  so  the  soundness 
of  GHL  can  be  used  to  prove  the  soundness  of  the  other  systems.  GHL  is 
manifestly  not  a  complete  system  for  reasoning  about  concurrent  programs, 
since  it  does  not  address  questions  of  liveness.  It  is  not  clear  how  to  use  our 
semantics  to  prove  completeness  of  GHL  for  the  class  of  properties  it  can 
express. 

A  method  for  proving  liveness  properties  of  programs  is  given  in  [12].  It 
considers  a  simple  language  that  is  essentially  the  same  as  language  L  except 
without  the  new  statement.  The  method  explicitly  assumes  a  complete 
program  n,  and  is  based  upon  temporal  logic  plus  the  following  single  axiom: 

Atomic  Action  Axiom :  For  any  atomic  action  n,7  of  II: 

af(n,7)  D  Oofter(n,l) 

To  prove  the  soundness  of  this  axiom,  we  must  show  that 

□  Mn.-y)  D  <Mc*(n,lf)) 

holds  for  every  substatement  and  atomic  action  11,7  of  n.  This  is  intu¬ 
itively  clear,  since  the  language  contains  only  fair  cobegin  statements,  and 
is  derivable  from  our  axioms  by  induction  on  the  sire  of  n.  The  above 
Atomic  Action  Axiom  then  follows  easily  from  our  liveness  axiom  for  com¬ 
plete  programs,  the  liveness  axioms  for  the  individual  statements,  plus  the 
Composition  Principle.  The  additional  axioms  given  in  [12]  for  weakly  and 
strongly  fair  semaphore  operations  cam  similarly  be  derived  from  the  ones  1 
gave  earlier. 


8  Conclusion 


I  have  given  an  axiomatic  semantics  for  a  simple  concurrent  programming 
language  L,  and  have  indicated  how  the  same  method  can  be  applied  to 
more  complicated  language  constructs.  Most  of  this  paper  has  been  devoted 
to  developing  the  fundamental  ideas  upon  which  the  method  is  based.  The 
axioms  themselves  are  reasonably  simple — simple  enough  so  I  feel  that  they 
do  provide  an  understanding  of  the  language  constructs.  For  example,  the 
difference  between  a  weakly  fair  and  a  strongly  fair  semaphore  is  described 
quite  concisely  and  precisely  by  their  respective  axioms. 

A  programming  language  semantics  provides  a  logical  basis  for  a  proof 
system  for  reasoning  about  programs  in  the  language.  One  can  talk  about 
the  soundness  and  completeness  of  the  proof  system  in  terms  of  the  seman¬ 
tics.  Note  that  it  makes  no  sense  to  talk  about  soundness  and  completeness 
of  the  semantics.  Indeed,  the  semantics  .MlSj  of  a  program  can  include  con¬ 
tradictory  axioms;  this  simply  means  that  there  are  no  valid  behaviors  for 
S,  so  there  is  something  wrong  with  the  program,  not  with  the  semantics. 

The  obvious  task  now  is  to  investigate  existing  proof  systems  in  terms 
of  this  semantics.  Unfortunately,  such  an  undertaking  is  beyond  the  scope 
of  this  paper.  However,  some  brief  remarks  are  in  order.  The  Generalized 
Hoare  Logic  (GHL)  presented  in  [4]  and  [9]  introduced  at,  in,  and  after 
as  predicates  rather  than  variables.  The  relation  ||  used  in  [4]  is  just  the 
relation  ±. 

The  semantics  of  GHL  formulas  was  not  stated  with  sufficient  precision 
in  [4],  since  the  relation  between  the  statement  S  and  its  name,  denoted  'S', 
was  never  made  clear.  A  close  examination  of  GHL  reveals  that  there  is  an 
implicit  complete  program  n,  and  that  if  5  is  the  substatement  n,7  of  n, 
then  a  formula  written  in  terms  of  S  should  really  be  written  in  terms  of 

n,r 

To  verify  the  soundness  of  GHL,  one  must  express  the  GHL  formula 
{P}S{(?}  as  a  temporal  logic  formula.  As  explained  in  [9],  it  suffices  to 
consider  the  case  P  =  Q,  for  which  the  definition  is  simply: 

{P}s{P}  {p}<n,7>{/>} 

where  5  is  the  substatement  n,7  of  the  implied  complete  program  n.  The 
soundness  of  the  general  rules  for  reasoning  about  GHL  formulas  follows 
easily  from  their  interpretation  as  temporal  logic  formulas.  The  soundness  of 
the  axioms  and  rules  given  in  [4]  for  each  language  construct  can  be  deduced 


Vr/  :  {in(S)  A  (5](i()  =  r/)}  (S)  {after{S)  A  x()  =  17} 

Note  that  the  rules  for  reasoning  about  these  generalized  dynamic  logic 
predicates  imply  that 

at(S)  D  ((5j(x()  =  n)  =  (exp  =  q)) 

The  liveness  axiom  for  a  nonatomic  assignment  is  simply 

□  0^c/(S)  3  O-'in(S) 
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liveness  requirements  one  could  make  in  this  case,  since  the  value  of  the 
expression  exp  could  change.  One  reasonable  possibility  is  the  following: 

□  0(-<4cf(5)  A  type.valid(x(),exp()))  D 

Allowing  a  more  general  form  of  aliasing,  such  as  the  one  defined  in  [10], 
presents  a  similar  problem  if  one  requires  that  an  assignment  which  would 
violate  an  aliasing  constraint  cause  the  process  to  hang  up.  One  approach 
to  this  is  to  put  the  aliasing  constraints  in  the  state,  just  as  I  did  with  type 
constraints.  The  new  state  components  would  correspond  to  the  “location” 
values  often  used  to  handle  aliasing. 

7.5  Nonatomic  Operations 

Every  construct  that  I  have  mentioned  specifies  the  atomic  actions.  For 
example,  I  have  defined  the  semantics  only  of  an  atomic  assignment  state¬ 
ment.  It  is  easy  to  give  the  semantics  of  an  assignment  statement  with 
smaller  atomic  operations.  For  example,  an  assignment 

(x)  :=  (exp) 

in  which  the  evaluation  of  exp  and  the  changing  of  x  are  distinct  atomic 
operations  can  be  represented  by 

(t  :=  exp);  (x  :=  t) 

where  t  is  an  implicit  variable.  A  similar  translation  is  possible  when  the 
evaluation  of  the  right-hand  side  is  broken  into  smaller  atomic  operations; 
it  is  described  in  [4]. 

The  situation  changes  when  no  atomicity  is  specified.  For  example,  con¬ 
sider  an  assignment  statement  x  :=  y  +  1  that  has  the  expected  effect  only 
if  x  and  y  are  not  modified  by  any  other  operation  during  the  course  of 
its  execution.  If  any  such  modification  does  take  place,  then  x  may  be  set 
to  any  value  consistent  with  its  type.  We  can  think  of  this  assignment  as  a 
compound  statement  for  which  we  know  nothing  about  its  internal  structure 
except  its  partial  correctness  property  (when  executed  alone)  and  the  fact 
that  it  always  terminates  (unless  the  process  executing  it  is  starved). 

Handling  such  nonatomic  operations  requires  a  new  class  of  state  pred¬ 
icate — the  “generalized  dynamic  logic”  predicates  [S]P  introduced  in  [7]. 
The  second  assignment  axiom  for  an  atomic  assignment  is  replaced  by  the 
following  one  for  a  nonatomic  assignment  x  :=  exp: 
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While  this  method  of  handling  procedure  calls  works  only  for  nonrecur¬ 
sive  procedures,  the  basic  idea  applies  to  recursive  ones  as  well.  Replacing 
a  procedure  call  by  the  body  of  the  procedure  produces  an  infinite  program 
text  for  recursive  procedures;  but  nowhere  have  I  made  use  of  the  assump¬ 
tion  that  the  program  text  is  finite.  Of  course,  the  compositional  method  of 
recursively  defining  no  longer  terminates  with  a  finite  set  of  axioms. 

However,  the  definition  can  be  viewed  as  an  algorithm  for  enumerating  an 
infinite  collection  of  axioms. 

Thus,  adding  recursion  means  that  .M[S]  consists  of  an  infinite  set  of 
axioms.  It  is  in  this  case  that  the  distinction  between  a  semantics  and  a 
proof  system  becomes  evident.  An  infinite  set  of  axioms  is  unsatisfactory 
as  a  proof  system,  because  ordinary  logic  provides  no  way  of  deducing  a 
conclusion  whose  correctness  is  based  upon  an  infinite  set  of  assumptions. 
Such  deductions  are  required  to  prove  nontrivial  properties  of  recursive  pro¬ 
grams.  Thus,  I  have  not  provided  a  proof  system  for  programs  with  recursive 
procedures. 

On  the  other  hand,  a  semantics  is  concerned  with  validity,  not  proof. 
The  meaning  of  a  program  II  is  the  set  of  behaviors  that  satisfy  the  axioms 
in  Min},  and  this  is  well-defined  even  for  an  infinite  set  of  axioms.  The 
problem  of  proof  systems  is  discussed  in  the  conclusion. 

7.4  More  General  Types  and  Aliasing 

Let  us  now  consider  a  language  in  which  a  type  mismatch  does  not  pro¬ 
duce  an  illegal  program,  but  generates  “incorrect”  behavior.  As  mentioned 
earlier,  this  requires  adding  predicates  of  the  form  type(x)  =  . . . ,  which 
are  syntactic  predicates  if  types  can  be  determined  syntactically  and  state 
predicates  if  types  are  dynamic. 

First,  suppose  that  a  type  mismatch  in  the  assignment  i  :=  exp  causes 
x  to  be  set  nondeterministically  to  any  value  in  its  range.  This  is  easily 
represented  by  changing  axiom  2  of  the  assignment  to  the  following,  where 
type.valid(x,  rj)  is  true  if  and  only  if  the  type  of  x  permits  it  to  be  assigned 
the  value  rj. 

Vt)  :  {at(S)  A  exp()  =  rj}  (S) 

{after{S)  A  (x()  =  n  V  -<type-valid(x(),  q))} 

Next,  suppose  that  a  type  mismatch  causes  the  assignment  to  “hang  up”, 
effectively  deadlocking  the  process.  This  requires  that  axiom  4  be  changed 
so  it  does  not  demand  termination  in  this  case.  There  are  several  different 


Note  that  pS  i1(S,i,'i,left())  is  the  exp  of  exp!£,  with  all  component  vari¬ 
ables  appropriately  renamed,  and  similarly  for  ps,j,^[S,j,  p,  left{)). 

It  is  straightforward  to  extend  this  approach  to  guarded  communication 
commands  such  as  { exp  — *  x?£),  which  means  that  the  communication 
action  may  be  carried  out  only  if  exp  has  the  value  true.  The  new  safety 
axiom  is  obtained  from  the  above  in  much  the  same  way  that  the  safety 
axiom  for  the  P(s)  semaphore  operation  is  obtained  from  the  corresponding 
axiom  for  the  assignment  statement — the  guards  here  playing  the  part  of 
the  enabling  condition  a  >  0  for  the  P(s)  operation. 

There  are  several  different  choices  of  liveness  properties  that  one  can 
require  of  these  channels.  They  are  all  basically  simple  to  express  with 
temporal  logic  formulas.  However,  their  formal  statement  requires  some 
careful  manipulation  of  syntactic  predicates,  which  I  won’t  bother  doing. 

The  safety  properties  of  CSP-like  communication  primitives  are  expressed 
more  easily  with  a  formal  semantics  based  only  upon  externally  observable 
actions,  such  as  [II].  When  shared  variables  are  not  allowed,  such  a  seman¬ 
tics  can  define  the  meaning  of  a  process  as  the  set  of  possible  communications 
it  can  engage  in.  However,  this  kind  cf  semantics  does  not  seem  capable  of 
handling  liveness  properties  easily. 

7.3  Procedures 

Although  language  L  does  not  have  procedures,  its  new  statement  contains 
the  basic  mechanism  needed  for  procedure  calls.  A  call  of  a  nonrecursive 
procedure  can  be  simulated  by  replacing  the  procedure  call  by  new  state¬ 
ments  plus  the  body  of  the  procedure.  For  example,  let  proc  be  a  procedure 
with  a  declaration 

procedure  proc(a  :  integer,  var  b  :  boolean  )  body 

in  which  its  first  argument  is  call  by  value  and  its  second  is  call  by  name. 
The  call  proc(x  +  y,  z)  can  be  translated  to 

new  a  init  x  +  y  in  new  b  alias  z 

in  body  ni  ni 

To  handle  call  by  reference  parameters,  one  needs  to  introduce  pointer  vari¬ 
ables  into  the  language.  Of  course,  aliasing  and  procedure  calls  become  more 
interesting  when  pointers  and  arrays  are  introduced,  but  a  discussion  of  the 
problems  raised  by  pointers  and  arrays  is  beyond  the  scope  of  this  paper. 


occur  when  s  has  the  value  zero.  Several  liveness  axioms  have  been  proposed 
for  the  semaphore.  Probably  the  most  common  are  weak  liveness,  expressed 
by 

( □  (s  >  0)  A  3  □-iat(P(s)) 

and  strong  liveness,  expressed  by 

(□0(«  >0)  A  DO>1^(P(j)))  3  □  ->af(P(s)) 

(They  are  discussed  in  [12].)  In  both  these  cases,  the  V(s)  operation  is  just 
an  ordinary  atomic  assignment. 

More  complicated  versions  of  the  semaphore  impose  a  specific  queueing 
discipline,  like  first-come-first-served,  on  the  execution  of  competing  P(s) 
operations.  They  may  require  adding  a  queue  of  waiting  processes  to  the 
state,  plus  predicates  to  describe  the  state  of  the  queue. 

7.2.2  CSP-Like  Communication  Primitives 

The  easiest  way  to  model  the  CSP  *!*  and  *?”  operations  is  in  terms  of 
channels.  We  include  the  operations  (x?£)  and  ( cxpl£  )  for  any  variable  x 
and  expression  exp.  They  denote  CSP-like  synchronous  communication  over 
a  channel  named  £.  We  modify  the  cobegin  statement  by  adding  a  clause 
of  the  form  channels  ft, . . . ,  £m,  which  declares  the  channel  names  &. 

As  explained  in  [9],  we  consider  communication  actions  to  be  actions  of 
the  channel,  so  Acf(S)  is  identically  false  if  5  is  a  !  or  ?  operation.  A 
channel  £  has  a  separate  atomic  action  for  every  pair  of  statements  (x?£), 
(exp!£)  contained  in  different  clauses  of  the  cobegin  in  which  £  is  de¬ 
clared.  This  atomic  action  is  axiomatized  much  like  the  assignment  state¬ 
ment  { x  :=  exp),  except  that  its  execution  changes  the  values  of  the  four 
control  variables  at(x?(),  after(x?£),  at(exp\£),  and  after(exp\£). 

To  do  this  formally,  we  must  extend  our  variable-naming  convention 
in  the  obvious  way  to  channel  variables  and  add  new  syntactic  predicates 
S,  7  € !  v  and  5,7  6  ?  v  to  assert  that  the  substatement  5, 7  is  a  !  or  ? 
operation  of  the  channel  named  v.  The  safety  axiom  for  the  declaration  of 
channel  £  will  be  something  like: 

V7, /*,*,/ 3t.  »  jt  j  :  S,«,7€!£(S)  A  S,j',/i€?£(S)  3 
Vq  :  (at(S,  17)  A  at(5,j,  7)  A  ps,in(S,i,~i,left())  =  q) 

U(S))  {after(S,i  7)  A  after(S,j,~i)  A  PsjAS,j,  p,left{))  =  q} 
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7.1.3  Write  Protection 


Imagine  a  situation  in  which  one  wants  the  variable  x  to  be  modified  only 
in  a  particular  statement,  but  to  be  accessible  elsewhere.  This  might  be 
expessed  by  the  following  statement  S: 

encapsulate  x  in  S' 

The  semantics  of  this  statement  are  described  formally  by: 

Vq  :  x()  =  n  3  (->i4ct(5))  <  (z()  =  tj) 

which  asserts  that  the  value  of  x  remains  unchanged  while  any  action  not 
in  5  is  executed. 


7.2  Synchronization  and  Communication 

The  bread  and  butter  of  concurrent  programming  language  constructs  are 
the  synchronization  and  interprocess  communication  mechanisms.  I  will 
discuss  only  two. 

7.2.1  Semaphores 

The  usual  semaphore  P  and  V  operations  are  variants  of  the  atomic  assign¬ 
ment  statement:  P(a)  looking  much  like  the  assignment  (s  :=  s  —  1 )  and 
V'(s)  looking  like  ( s  :=  a  +  1 ).  There  are  two  basic  differences.  First  of  all, 
the  P(s)  operation  may  be  performed  only  when  s  is  positive.  One  way  of 
expressing  this  is  to  change  the  first  axiom  of  the  assignment  statement  to: 

/lct(P(a))  D  (af(P(s))  A  s  >  0) 

However,  this  would  require  changing  other  axioms,  since  deadlock  is  rep¬ 
resented  by  the  absence  of  any  possible  actions,  and  the  axiom  given  above 
for  the  complete  program  asserts  that  this  is  impossible. 

The  other  way  of  handling  this  is  to  allow  only  stuttering  actions  of  P(s) 
to  occur  when  s  <  0.  This  is  achieved  by  replacing  the  second  axiom  of  the 
assignment  statement  with  the  following: 

Vq  :  (at(P(s))  A  (x()  =  rj)}  (P(s)>  {after(P{s))  A  (z()  =  q-  1  >  0)} 

The  second  change  that  must  be  made  to  the  assignment  axioms  is  in 
the  iiveness  condition.  We  can  no  longer  require  that  an  infinite  number  of 
actions  of  P(s)  cause  the  operation  to  be  completed,  since  they  might  all 


7  Other  Language  Features 

While  I  have  given  a  formal  semantics  only  for  the  simple  language  L,  action- 
axiom  semantics  can  be  used  to  describe  a  wider  variety  of  concurrent  pro¬ 
gramming  language  constructs  than  any  other  method  I  know  of.  In  this 
section,  I  will  consider  a  few  interesting  constructs.  In  doing  so,  I  will  not 
bother  to  give  the  usual  axioms  that  describe  the  relations  among  control 
variables  and  among  action  predicates. 

7.1  Constructs  That  Constrain  Their  Environment 

Most  language  constructs  constrain  the  behavior  of  their  components.  For 
example,  an  if  statement  determines  when  its  then  and  else  clauses  can  be 
executed.  The  following  three  language  constructs  constrain  the  behavior  of 
a  larger  program  containing  them.  They  are  therefore  impossible  to  spec¬ 
ify  in  a  compositional,  purely  behavioral  semantics.  It  is  the  Composition 
Principle  that  makes  them  expressible  with  action-axiom  semantics. 

7.1.1  The  assign  processor  Command 
As  described  above,  the  statement 

assign  processor  to  . . . 

directs  the  compiler  to  guarantee  that  the  body  of  the  statement  gets  its 
share  of  computing  cycles,  so  it  is  not  starved.  This  is  expressed  by  the 
axiom: 

in(S)  D 

7.1.2  Atomic  Actions 

One  might  want  to  introduce  “angle  brackets”  as  a  language  construct,  so 
( S  )  denotes  that  5  is  to  be  executed  as  an  indivisible  atomic  action.  This  is 
done  by  requiring  that  no  other  actions  are  interleaved  with  the  executions 
of  S,  expressed  formally  by: 

Act({  S  ))  D  in([  5 ))  <  Act({  5 )) 
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Abstract 

A  constraint  is  a  relation  among  program  variables  that  is 
maintained  throughout  execution.  Type  declarations  and 
a  very  general  form  of  aliasing  can  be  expressed  as  con¬ 
straints.  A  proof  system  based  upon  the  interpretation  of 
Hoare  triples  as  temporal  logic  formulas  is  given  for  rea¬ 
soning  about  programs  with  constraints.  The  proof  system 
is  shown  to  be  sound  and  relatively  complete,  and  example 
program  proofs  are  given. 

1  Introduction 

Type  declarations  and  aliasing  relations  have  traditionally 
been  thought  of  as  unrelated  concepts.  However,  both 
can  be  viewed  as  specifying  properties  that  do  not  change 
during  program  execution.  This  view  leads  to  a  uniform 
method  for  reasoning  about  types  and  aliasing  in  which 
the  usual  Hoare  logic  triples  are  regarded  as  temporal  logic 
formulas. 

Aliasing  two  variables  x  and  y  means  they  always  have 
the  same  value.  This  is  usually  implemented  by  allocating 
the  same  memory  location  to  z  and  y,  thereby  ensuring 
that  both  variables  are  changed  whenever  either  is  assigned 
a  new  value.  However,  they  could  be  allocated  separate 
memory  locations  and  both  updated  on  an  assignment  to 
either.  Viewing  aliasing  as  defining  certain  relationships 
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between  the  values  of  variables,  with  no  implication  about 
storage  allocation,  allows  more  general  kinds  of  aliasing  and 
leads  to  a  simple  method  for  reasoning  about  aliasing. 

To  express  a  more  general  form  of  aliasing,  we  introduce 
the  var  statement.  To  illustrate  its  use,  suppose  a  pro¬ 
gram  computes  a  temperature,  and  that  some  times  it  is 
convenient  to  refer  to  that  temperature  in  degrees  Fahren¬ 
heit  and  other  times  in  degrees  Celsius.  We  will  write  the 
statement 

var  /,  e  :  real  constraints  /  =  9  *  e/5  +  32  in  5 

which  declares  variables  f  and  c  within  statement  5  to  be 
of  type  real  and  to  be  aliased,  so  that  if  the  value  of  /  is 
a  temperature  in  degrees  Fahrenheit,  then  the  value  of  c 
is  that  temperature  in  degrees  Celsius.  Changing  /  causes 
a  corresponding  change  to  c,  and  vice-versa.  Notice  that 
this  more  general  form  of  aliasing  cannot  be  implemented 
simply  by  allocating  overlapping  memory  locations  to  /  and 
c. 

The  constraints  clause  of  a  var  statement  is  a  directive 
that  a  specified  predicate — in  our  example,  the  aliasing  re¬ 
lation  /  =  9«c/5+32 — be  maintained  as  an  invariant,  which 
means  that  execution  is  aborted  if  the  predicate  becomes 
false. 

A  type  declaration  can  also  be  viewed  as  an  invariant,  so 
it  can  be  specified  in  a  constraints  clause.  If  we  take  the 
view  that  the  type  of  a  variable  defines  the  set  of  values 
that  variable  can  have,  then  declaring  a  variable  /  to  be  of 
type  real  is  the  same  as  requiring  that  the  predicate  /  6  Z 
be  true  throughout  execution,  where  Z  is  the  set  of  real 
numbers.1  Thus,  we  could  eliminate  the  rear  from  the 
above  var  statement  and  add  the  constraint  x,y  £  Z.  Since 
doing  so  would  make  the  statement  less  readable,  we  will 
retain  the  customary  syntax  for  type  declarations. 

Aliasing  and  typing  can  be  viewed  in  terms  of  constraints 
because  they  are  static  properties.  While  dynamic  proper¬ 
ties,  such  as  the  values  of  variables,  can  be  changed  by 
execution  of  a  program  statement,  static  properties  can¬ 
not.  (In  most  languages,  like  the  one  considered  here,  a 

■For  simplicity,  we  assume  A  is  the  infinite  set  that  mathematicians 
call  the  real  numbers,  thereby  avoiding  the  problems  that  round-off 
errors  would  introduce  for  reasoning  about  equality  of  expressions. 


declaration  is  not  a  complete  statement  but  rather  part  of 
a  statement.)  The  methods  we  develop  for  reasoning  about 
aliasing  and  types  can  be  used  to  reason  about  any  static 
property. 

Returning  to  aliasing,  consider  a  more  complicated  ex¬ 
ample  in  which  a  program  refers  a  point  in  terms  of  both 
its  Cartesian  coordinates  z,  y  and  its  polar  coordinates  r,8. 
Variables  z,  y,  r,  and  8  are  declared  as  follows. 

var  z,  y,  r  :  real,  8  :  (0, 2  «  z) 
constraints  z  =  r  •  cos(0)  and  y  =  r  *  sin (9) 
in  5 

(The  type  declaration  for  8  states  that  it  is  a  real  in  the 
range  0  <  8  <  2ff.)  We  would  like  this  declaration  to  mean 
that  when  x  is  changed,  r  and  6  are  changed  according 
to  the  constraints,  but  y  is  not.  However,  the  fact  that  y 
should  not  change  is  based  upon  the  knowledge  that  z  and 
y  are  independent  coordinates,  which  is  not  something  dis¬ 
cernible  in  the  above  statement.  An  additional  constraint 
is  needed  to  specify  that  assigning  to  x  should  not  change 
the  value  of  y  and  vice-versa;  we  write  this  constraint  as 
z  J.  y.  Similarly,  r  and  8  should  be  independent,  so  as¬ 
signing  a  value  to  either  r  or  8  does  not  change  the  other. 
Hence,  the  additional  constraint  r  i.  8  is  needed.  The  fol¬ 
lowing  declaration  of  z,  y,  r,  and  8  gives  the  desired  aliasing 
relations. 

var  z,  y,  r  :  real,  8  :  [0, 2  *  ir) 

constraints  z  =  r  *  cos (8)  and  y  =  r  •  sin(0) 
and  z  _L  y  and  r  ±8 

in  S 

Finally,  observe  that  the  var  statement  can  express  forms 
of  aliasing  traditionally  implemented  by  overlapping  stor¬ 
age.  The  statement 

var  fall,  right-J  '■  natural 
constraints  right-4  —  /“M  mod  16 
in  5 

aliases  variable  rights  to  the  right-most  four  bits  of  full, 
where  natural  denotes  the  nonnegative  integers.  Moreover, 
the  decln  ration  ensures  the  desired  semantics  even  on  a 
computer  where  integers  are  not  stored  in  binary. 

It  is  probably  impossible  for  a  compiler  to  handle  our 
form  of  aliasing  in  all  its  generality.  While  the  Fahren¬ 
heit/Celsius  and  full/right-4  examples  do  not  pose  difficult 
compiling  problems,  consider  what  happens  if  the  follow, 
ing  statements  appear  in  the  body  of  the  above  var  z,  y,  r,  9 
statement: 

read (z,  y) ;  writ e(8) 

Input  values  a,  b  with  a  /  0  produce  the  output  value 
arctan(6/a) — something  no  present-day  compiler  is  likely 
to  figure  out. 

We  are  interested  in  our  general  form  of  aliasing  in  order 
to  reason  about  implicit  variables — variables  representing 
portions  of  the  program  state  that  are  not  directly  vis¬ 
ible  to  the  programmer.  For  example,  in  a  concurrent 


programming  language  with  primitives  to  perform  buffered 
message-passing,  messages  sent  but  not  yet  delivered  are 
part  of  the  state  that  must  be  described  by  implicit  vari¬ 
ables.  (The  p  and  a  multisets  of  [18J  are  such  variables  ) 
Implicit  variables  often  involve  complex  aliasing  relations. 
For  some  message-passing  schemes,  a  channel  is  modelled 
by  having  an  implicit  variable  in  a  sender  aliased  to  an  im¬ 
plicit  variable  in  the  receiver.  Even  more  complex  aliasing 
occurs  when  a  channel  emanating  from  a  network  is  aliased 
to  the  union  of  the  channels  emanating  from  its  compo¬ 
nents.  The  CSP  language  [10]  supports  such  a  hierarchical 
channel-naming  scheme. 

In  the  Generalized  Hoare  Logic  (GHL)  [12,14],  a  logic  for 
concurrent  programs,  one  must  reason  about  state  compo¬ 
nents  that  describe  the  control  state.  In  the  original  pre¬ 
sentation  of  GHL,  the  control  state  was  modelled  by  at,  in, 
and  after  predicates,  where  at (5)  is  true  when  control  is 
at  the  entry  point  of  statement  5,  after(S)  is  true  when 
control  is  at  the  exit  point  of  statement  5,  and  in(S)  is 
true  when  af(S)  is  true  or  control  is  at  a  component  of  5. 
Axioms  were  given  to  describe  the  relations  among  these 
predicates.  Thus,  if  5  is  the  statement  $,;5*,  the  axioms 
of  GHL  state: 

at(5)  =  af(Si) 
o/ter(S)  s  afler(Sj) 

itt(S)  =  at(S)  V  in(Si)  V  in(S«) 
after(Si)  =  at(S2) 

GHL  included  ad  hoe  rules  for  reasoning  about  these  control 
predicates.  However,  by  viewing  the  control  predicates  as 
implicit  variables,  and  considering  the  above  relations  not 
as  equality  of  predicates  but  as  aliasing  relations  among 
variables,  we  can  reason  about  the  control  state  with  ex¬ 
actly  the  same  rules  used  to  reason  about  the  values  of  ordi¬ 
nary  program  variables.  This  is  described  in  detail  in  [15]. 

2  Primitives  for  Constrained 
Execution 

A  var  statement,  like  the  one  for  the  Cartesian/polar  co¬ 
ordinate  example,  specifies  three  things: 

•  The  names  of  new  variables — z,  y,  r,  and  8  in  the 
example. 

•  Constraints  the  new  variables  must  satisfy,  including 
those  given  explicitly  by  the  constraints  clause  and 
those  implicit  in  the  type  declarations.  In  the  example, 
the  constraints  are: 

z  g  Z  x  =  r  »  cos(0) 

y&Z  y  =  r.sin(0) 

r  €  Z  x  1  y 

8  €  Z  A  0  <  0  <  2tr  r  16 

•  Other  independence  constraints  invoK  ing  the  new  vari¬ 
ables.  In  the  example,  there  is  the  implicit  assumption 
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that  x ,  y,  r,  and  8  are  not  aliased  to  any  other  vari¬ 
ables,  except  perhaps  variables  declared  in  the  body 
of  the  var  statement.  Thus,  there  are  implicit  con¬ 
straints  x  1  q  for  all  variables  q  declared  outside  the 
var  statement,  and  similarly  for  y,  r,  and  9. 

Instead  of  reasoning  directly  about  the  var  statement, 
three  primitive  statements  are  introduced,  each  of  which 
performs  one  of  the  above  functions.  These  statements  can 
be  used  to  model  the  var  statement  and  the  aliasing  of 
implicit  variables  described  above. 

The  new  statement  is  used  to  define  new  variable  names, 
where 

new  x,  ,  xt ,  . . . ,  x,  in  5 

defines  x,,  x2,  . . .  ,  xn  to  be  new  variable  names  for  use 
within  5.  These  variable  names,  plus  any  defined  in  a 
new  statement  containing  this  one,  can  be  referenced  from 
within  5.  The  usual  scoping  rules  apply,  so  that  a  variable 
x,  defined  by  this  new  statement  is  different  from  any  other 
variables  with  the  same  name  defined  by  a  different  new 
statement. 

The  declare  statement  is  used  to  specify  constraints. 
The  statement 

declare  C  in  5 

where  C  is  a  predicate,  indicates  that  C  is  to  be  maintained 
during  execution  of  S  and  that  abortion  is  to  occur  if  this 
becomes  impossible.  If  5  contains  a  nondeterministic  step, 
such  as  a  nondeterministic  assignment  statement,  then  the 
choice  must  be  made  (if  possible)  so  that  the  truth  of  C  is 
maintained. 

Finally,  the  may  alias  statement  is  used  to  specify  inde¬ 
pendence  relations  implicit  in  a  var  statement.  The  state¬ 
ment 

x  may  alias  x(,  xj, ... ,  x*  in  5 

specifies  that,  during  execution  of  5,  the  value  of  x  is  inde¬ 
pendent  of  all  variables,  other  than  xlt  x*, . . . ,  x„  declared 
in  the  context  of  this  statement.  Thus,  this  statement  spec¬ 
ifies  constraints  x  JL  q  for  all  variables  q  not  in  the  list  Xj, 

x: . x„.  Although  may  alias  specifies  constraints,  it 

cannot  be  modeled  with  a  declare  statement  because  that 
would  require  explicitly  writing  relations  x  J.  p  for  every 
variable  name  p  different  from  the  x,-,  and  there  could  be 
an  infinite  number  of  such  names. 

The  new,  declare,  and  may  alias  statements  can  be 
used  to  model  a  var  statement.  The  var  x,  y,  r,6  example 
could  be  represented  as: 

new  x,  y,  r,  6  in 

x  may  alias  x,  y,  r,  6  in 
y  may  alias  x,  y,  r,  8  in 
r  may  alias  x,  y,  r,  9  in 
9  may  alias  x,  y,  r,  9  in 

declare  x  e  JZ  and  y  S  R  and 

r  €  R  and  9  €  [0, 2r)  and 


x  =  r  »  cos(0)  and  y  =  r  •  sin(0) 
and  x  J.  y  and  r  IB 
in  5 

In  general,  let  . .  ,  x„  y,,  ...  ,  ym  be  n  +  m  dis¬ 

tinct  variable  names,  and  let  C  be  a  predicate  constructed 
from  the  m  variables  y,-  plus  zero  or  more  of  the  x,.  The 
statement 

var  x, :  7\, . . . ,  x„  :  Tn  constraints  C  in  S 
is  modeled  by 

new  X|,  xt, ....  x,  in 

x,  may  alias  x, . xm,  y,, ... ,  ym  in 

...  x,  may  alias  x,, ...  ,  x„  y,,  ...  ,  ym  in 
declare  C  and  xt  €  T,  and 
. . .  and  x,  e  Tn 

in  5 

3  Reasoning  About  Constraints 

Our  goal  is  to  prove  partial  correctness  formulas  of  the 
form  {P}  S  {Q},  as  first  proposed  by  Hoare  [8].  To  reason 
about  constrained  execution,  we  interpret  such  a  formula 
as  a  temporal  assertion  about  the  executions  of  S — namely, 
{P}  5  {<?}  is  equivalent  to  the  assertion  that  any  terminat¬ 
ing  execution  of  S  beginning  with  a  state  in  which  P  is  true 
ends  in  a  state  in  which  Q  is  true.  Thus,  we  are  viewing 
{ P}S  {Q}  as  a  temporal  formula,  which  is  not  how  it  is 
usually  viewed  in  Hoare’s  logic. 

One  reasons  about  such  temporal  assertions  with  tempo¬ 
ral  logic.*  The  only  knowledge  of  temporal  logic  needed  to 
understand  this  paper  is  that  the  temporal  formula  O  A  is 
true  of  a  statement  S  if  and  only  if  A  remains  true  through¬ 
out  every  possible  execution  of  S.  The  only  formal  rules 
for  reasoning  about  temporal  logic  formulas  that  we  need 
are  the  following,  which  are  immediate  consequences  of  the 
definition  of  □. 

Strong  Neceaaitation  Rule: 

P  =>  Q 
aP  =>  oQ 

Multiplicative  Axiom: 

□  (AaB)  =  DAA  dB 

To  apply  temporal  logic  to  program  executions,  we  need 
to  know  what  actions  are  atomic.  For  example,  the  formula 
□  A  asserts  that  A  is  true  before  and  after  each  atomic  ac¬ 
tion.  In  general,  an  atomic  action  represents  the  execution 
of  a  primitive  statement  that  can  change  the  value  of  a  vari¬ 
able.  Execution  of  an  assignment  statement  is  the  only  kind 
of  atomic  action  needed  to  describe  the  c’  ss  of  languages 
considered  in  this  paper. 

’See  [16)  for  an  elementary  discussion  of  temporal  logic  and  the  ap¬ 
pendix  of  [13|  for  the  more  advanced  temporal  logic  needed  to  formal¬ 
ize  our  method. 
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A  program  execution  is  a  sequence  of  atomic  actions. 
The  possible  executions  of  the  statement 

declare  C  in  5 

are  all  those  executions  of  5  for  which  C  is  true  through¬ 
out  the  execution — that  is,  those  executions  for  which  DC 
is  true.  This  leads  immediately  to  an  inference  rule  for 

declare: 

declare  Rule: 

ac~{P)S{Q} 

{P}  declare  C  in  S  {<?} 

In  this  rule,  the  hypothesis  states  that  the  predicate 
{P}  S  { Q}  is  true  or  that  C  does  not  hold  throughout  all 
executions  of  5. 

Note  that  in  our  temporal  logic  interpretation  of  partial 
correctness  formulas,  the  pre-  and  postconditions  are  asser¬ 
tions  about  the  program  state,  so  they  must  be  Boolean¬ 
valued  functions  on  the  state.  In  particular,  they  cannot 
contain  temporal  operators  like  □. 

All  the  usual  inference  rules  for  partial  correctness  for¬ 
mulas  (see  |8])  still  hold  under  this  new  interpretation.  For 
example, 

Rule  of  Consequence: 

P‘\-P,  {P)  S  {<?},  Q\-Q' 

{/*}  5  {<?'} 

This  rule  allows  the  precondition  of  a  partial  correct¬ 
ness  formula  to  be  weakened  and  the  postcondition  to  be 
strengthened. 

The  only  new  general  rule  needed  for  reasoning  about 
constraints  is  the 

Constraint  Strengthening  Rule: 

{PaC}S  (Q  V  ->C} 

□  C  ~  { P}S[Q } 

To  show  the  validity  of  this  rule,  observe  that  the  hypothe¬ 
sis  asserts  that  every  terminating  execution  of  5  that  begins 
with  P  AC  true  terminates  with  Qv->C  true.  Another  way 
of  saying  this  is: 

For  any  terminating  execution  of  S:  C  true  of  the 
initial  state  implies  that  if  P  is  true  of  the  initial 
state  then  Q  is  true  of  the  final  state  or  -,C  is  true 
of  the  final  state. 

The  conclusion  asserts  the  following: 

For  any  execution  of  S:  C  true  throughout  the 
execution  implies  that  if  P  is  true  of  the  initial 
state  and  the  execution  terminates,  then  Q  is  true 
of  the  final  state. 


It  should  now  be  clear  why  the  hypothesis  implies  the  con¬ 
clusion. 

The  expression  *  X  y,  introduced  above  for  stating  in¬ 
dependence,  can  be  given  a  precise  meaning  as  a  temporal 
formula.  The  formal  definition  is  given  in  the  Appendix. 
Intuitively,  *  X  y  is  the  temporal  formula  asserting  that  if 
the  next  atomic  action  of  the  program  is  an  assignment  to 

x,  then  the  assignment  does  not  change  the  value  of  y,  and 
if  the  next  atomic  action  is  an  assignment  to  y,  then  it  does 
not  change  the  value  of  x. 

The  most  general  kind  of  temporal  formula  we  write  is 
of  the  form 

DC  =>  {P}S{Q}. 

Because  temporal  formulas  cannot  appear  in  pre-  and  post¬ 
conditions,  X  relations  can  appear  only  in  C,  which  means 
they  appear  only  in  the  form  D(z  X  y).  The  temporal 
formula  □(:  X  y)  asserts  that  no  assignment  to  z  during 
execution  causes  the  value  of  y  to  change,  and  vice-versa. 

Rules  for  reasoning  about  X  could  be  deduced  from  its 
formal  definition.  Instead,  we  state  as  axioms  two  proper¬ 
ties  that  seem  to  be  sufficient  for  reasoning  about  programs. 
An  obvious  axiom  is: 

Commutativity  Axiom: 

z  ±  y  =  y  X  x 

Another  obvious  axiom  states  that  if  z  is  always  equal  to 

y,  then  D(y  X  z)  implies  d(z  X  z).  While  this  rule  is 
sufficient  for  our  examples,  the  following  generalization  is 
sometimes  needed. 

Substitution  Axiom:  For  any  (single-valued)  func¬ 
tion  /  of  n  arguments  and  for  any  variables  z,  y,, 

•  •  • ,  Vn 

□  (*  =  /(y I. -•-,»«)  A  y,  X  t  A  ...  A  y„  1 1) 

=>  □  (z  X  z) 

4  Axioms  For  a  Toy  Language 

In  the  preceding  section,  certain  general  rules  for  reasoning 
about  temporal  logic  formulas  were  given.  W'e  now  give 
language-specific  rules  and  axioms  for  a  toy  language.  The 
language  contains  the  usual  skip,  assignment  (:=),  con¬ 
catenation  (;),  and  while  constructs,  in  addition  to  the 
aforementioned  new,  declare,  and  may  alias  statements. 
As  usual,  there  is  one  rule  or  axiom  for  each  language  con¬ 
struct.  The  rule  for  declare  was  already  given. 

4.1  Assignment 

Consider  the  standard  way  of  reasoning  about  assignment 
statements  in  Hoare’s  logic.  Assuming  there  is  no  aliasing, 
one  deduces 

{true}  z:=y+  1  {z  =  y-t-l}. 


This  formula  is  not  valid  when  aliasing  is  allowed,  because 
the  assignment  might  appear  in  the  body  of  a  var  statement 
that  aliases  x  to  equal  y,  in  which  case  the  postcondition 
x  =  y+1  would  be  false.  However,  this  postcondition  would 
be  satisfied  if  x  and  y  were  not  aliased,  which  means  that  it 
would  be  satisfied  if  we  constrained  execution  of  x  :=  y  + 1 
by  requiring  that  x  X  y  hold.  Hence,  the  rule  to  use  when 
aliasing  is  possible  is 

Orly  =>  {/me}  x  :—  y+  1  {*  =  y  +  1} 

(Remember  that  zly  cannot  appear  in  the  precondition 
because  temporal  formulas  may  not  appear  in  pre-  or  post¬ 
conditions.) 

More  generally,  the  Assignment  Axiom  in  Hoare’s  logic 
is 

{Qlcrp.y . . y„)}  x  :=  exp  {<?(*.  yi, . . .  ,  y.)} 

where  Q[x,yt, . . .  ,y»)  is  any  predicate  involving  only  the 
program  variables  x,yt, ...  ,yu,  and  exp  is  an  expression. 
Again,  this  axiom  is  valid  only  if  x,  the  target  of  the  as¬ 
signment,  is  not  aliased  to  any  of  the  y/s.  Therefore,  when 
aliasing  is  allowed,  the  correct  formula  is 

Assignment  Axiom: 

D|xly,  A  ...  Ariy,)  =» 

{<?(erp,y, . y„)}  x  exp  {<?(x,y, . y„)} 

4.2  May  alias 

Recall  that  the  statement 

x  may  alias  xt,  Xj,  ...,*„  in  5 
is  really  equivalent  to 

declare  A  in  5 

where  A  is  a  conjunction  of  terms  of  the  form  z  X  y,  for 
an  infinite  number  of  variables  y — namely,  every  y  that  is 
not  among  the  x,.  Therefore,  the  declare  rule  gives  the 
following: 

□  A  =>  {P}S{Q} 

{ P }  x  may  alias  xt,  . . x„  in  S  {Q}  1 

Now,  let  yi.  y»,  . . .  ,  ym  be  a  finite  number  of  variables,  all 
different  from  any  of  the  x,.  Then, 

A  =>  (rlj/i  A  ...  Arl  ym).  (2) 

Given 

□  (xXy,  A  ...  A  xXym)  =>  {P}  S  {<?} 
we  use  (2)  to  deduce 

□  A  =*  {P)  S  {<?} 

which  is  the  hypothesis  of  (1).  Therefore,  we  get  the  fol¬ 
lowing  inference  rule. 


may  alias  Rule: 

□  (xXy,  A  ...  A  x  X  ym)  => 

_ {P}  S  {Q},  V«,j:y,  #x, 

{P}  x  may  alias  x,,  . . .  ,  x„  in  5  {<?} 

•»» 

where  a  /  6  means  that  a  and  6  are  syntactically  different 
variable  names. 

4.3  New 

The  rule  for  the  new  statement  is  essentially  the  same  as 
the  one  for  ordinary  Hoare  triples — see  Rule  16  of  [1].  The 
statement 

new  zi  ,  . . .  ,  xa  in  5 

declares  that  the  variables  x<  are  different  from  all  vari¬ 
ables  declared  outside  the  statement.  It  is  equivalent  to 
substituting  for  all  free  (undeclared)  occurrences  of  x,  in  5 
another  variable  y,  that  is  not  used  anywhere  in  the  entire 
program.  Of  course,  when  reasoning  about  S  in  isolation, 
we  do  not  know  what  the  entire  program  is.  However,  since, 
we  are  concerned  only  with  a  particular  pre-  and  postcon¬ 
dition,  it  suffices  to  choose  the  y,  so  that  they  don’t  appear 
in  that  pre-  or  postcondition  or  in  5.  This  leads  to  the 
following  rule,  where  5[y,/xi,. . . ,ya/xBj  is  the  statement 
obtained  by  substituting  y ,■  for  every  free  occurrence  of  x, 
in  S,  for  »'  =  l,...,n. 

new  Rule:  For  any  distinct  variable  names  y1, 

. . .  ,  y„  not  occurring  free  in  P,  S,  or  Q: 

W  S[yi/*. . yn/x„]  {<?} 

{P}  new  x„  ...  ,  x„  in  S  {<?} 

Note  that,  unlike  [1],  initial  values  for  the  variables  x<  in 
5  are  not  assumed;  executions  containing  arbitrary  initial 
values  are  permitted. 

4.4  Remaining  Statements 

The  axioms  for  the  remaining  statements  are  just  the  or¬ 
dinary  Hoare  logic  partial  correctness  rules.  For  example, 
Hoare’s  rule  for  statement  concatenation  is: 

Statement  Concatenation: 

(Pj  S  «?’}.  {<?’}  S’  {(?} 

{P}  5;  5'  {<?} 

5  Examples 

5.1  No  Aliasing 

We  first  consider  an  example  in  which  there  is  no  aliasing— 
that  is,  there  are  no  constraints.  Let  5  be  the  statement 

var  x  :  real  in  y  :=  y  +  1; 

x  :=  y  +  3 


C-5 


We  will  prove  the  obvious  relation 

{y  =  l}S  {y  =  2}  (3) 

From  the  Assignment  Axiom,  we  get 

(3  true  =>  {y  =  1}  y  :=  y  +  1  {y  =s  2} 

Dx'ly  =>  {y  =  2}  x':=y  +  3  {y  =  2} 

Using  ordinary  propositional  logic  and  the  Strong  Necessi¬ 
tate  Rule,  the  antecedents  of  these  implications  can  be 
strengthened  to  get 

a(r'  1  yAx'  e  X)  =>  {y  =  1}  y  :=y-M  {y  =  2}  (4) 
□  (i'XjAi'6  je)  =>  {y  =  2}  x*  :=  y  +  3  {y  =  2}  (5) 

Combining  (4)  and  (5)  gives 

□  (r'XyAx'e*)  =s» 

{y  =  1}  y  :=  y  +  1  {y  =  2}  A  {y  =  2}  X1  :=  y  +  3  {y  =  2} 

Application  of  the  Statement  Concatenation  Rule  to  the 
consequent  of  this  yields 

□  (x'XyAx'e*)  *> 

{y=  1}  y:=y+l;  x1  :=  y  +  3  {y  «  2} 

The  declare  Rule  now  allows  us  to  conclude 

□  (x'Xy)  =>  (y  =  1} 

declare  *’  €  X  in 

y:=y+l;  x*:=y  +  3  {y  =  2} 

Applying  the  may  alias  rule  yields 

{y  =  1}  x'  may  alias  x*.  y  in 
declare  x*  £  X  in 
y  :=  y  +  1;  xf  :=  y  +  3  {y  =  2} 

Finally,  the  new  Rule  allows  us  to  deduce 

{y  =  1}  new  in 

x  may  alias  x,  y  in 
declare  x  €  X 

in  y  :=  y+ I;  x  :=  y  +  3  {y  s*  2} 

The  statement  in  this  formula  is  equivalent  to  our  origi¬ 
nal  statement  S,  according  to  the  method  of  modeling  var 
statements  described  in  Section  2,  so  the  desired  result  is 
proved. 

5.2  Simple  Aliasing 

Next,  let  S  be  the  same  as  above  except  with  x  and  y 
aliased: 

var  x  :  real  constraint  x  =  y  in  y  :s=  y  +  1; 

x  :=  y  +  3 

Formula  (3)  is  no  longer  valid  for  this  program.  Instead, 
we  have 

{y=l}S{y  =  5}  (6) 


The  proof  of  this  is  as  follows.  From  the  Assignment  Axiom, 
we  have 

C  true  =>  (y  =  1}  y  :=  y  +  1  {y  =  2} 

Dtrue  =>  {y  =  2}  x*  :=  y  +  3  {*’  =  5} 

Combining  these,  using  the  Statement  Concatenation  Rule, 
yields 

a  true  =>  {y  =  1}  S'  {z1  =  5} 
where  S'  is  the  statement 

y-y+l;  x':=y  +  3 

Applying  the  Rule  of  Consequence  to  this,  using  the  tau¬ 
tologies 

(x'  =  5)  =>  (y  =  5  V  x'  /  y) 

(y  =  1  A  x>  =  y)  =>  (y  s  1) 

we  conclude 

□  true  =>  {y  =  1  Ax'sy}  S' {y  =  Svx' y) 

The  Constraint  Strengthening  Rule  now  allows  us  to  deduce 

□  *'  =  V  =>  {y=  1}  5'  (y  s  5} 

Using  propositional  logic  and  the  Strong  Necessitation 
Rule,  we  can  strengthen  the  antecedent  of  the  implication 
to  obtain 

0(x'  =  y  A  x'e*)  =>  {y  »  1}  S'  {y  as  5} 

The  declare  Rule  now  yields 

{»*!)  declare  x/  =  y  and  x'  €  X  in  S'  {y  =  5} 

from  which  the  may  alia*  Rule  allows  us  to  deduce 

(y  =  1}  x*  may  aliaa  x1,  y  in 

declare  x'  =  y  and  x*  €  X  in 
S'  {y  =  5} 

Finally,  the  new  Rule  allows  the  conclusion 

{y  =  1}  new  x  in 

x  may  alias  x,  y  in 
declare  x  =  y  and  x  €  £  in 
y.-y+l 

x:=y  +  3  {y  =  5} 

This  is  just  what  is  required  to  prove  (6). 

5.3  Cartesian/Polar  Coordinates 

As  a  final  example,  let  S  be  the  following  statement, 
var  x,  y  :  real 

constraints  x  =  r  *  cos(0)  and  y  =  r  *  sin(fi) 
and  x  X  y  in  x  :=  2  •  x; 

y  :=  2  •  y 
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A  little  trigonometry  shows  that  if  r  is  initially  positive, 
then  executing  5  should  double  the  value  of  r  and  leave  0 
unchanged.  Thus,  the  following  should  hold: 

{r  =  r0  A  9  —  80}  S  (r  as  2r0  A  8  =  0O} 

However,  further  reflection  indicates  that  this  is  not  quite 
valid  because  executing  5  can  add  any  even  multiple  of  tr 
to  8  or  can  negate  r  and  add  any  odd  multiple  of  tr  to  8. 
Thus,  we  stipulate  that  r  >  0  and  0  <  0  <  2jt  remain  true 
throughout  execution,  and  prove 

□  (r  >  0  A  0  <  0  <  2ir)  =>■ 

{r  =  roA0  =  0o}  5  {r  =  2roA0  =  0o}  (7) 

Let  S'  be  the  statement 

x’  :=  2  *  x';  :=  2  *  y1. 

From  the  Statement  Concatenation  Rule  and  two  applica¬ 
tions  of  the  Assignment  Axiom,  we  deduce 

□  x'Xy'  s>  {x'  =  r0cos80  A  jr*  =  rosin0o}  S' 

{x'  =  2rocos0o  A  y'  =  2rosin0o} 

Now  ,  note  that  the  following  are  tautologies: 

(x'  =  r0  cos 8a  a  rcos8  —  r0  cos 0O  a  xf  =  rcosS) 

=>  (x1  =  rocos0o) 

(x'  =  2rocos0o)  =>  (rcos0  =  2rocos0o  V  x'  ^  rcos0) 

Similar  tautologies  apply  to  y*.  Therefore,  by  the  Rule  of 
Consequence  we  conclude 

Ox'  1  y' 

x'  =  rocos0o  A  rcos0  ss  rocos0o  AX1*  rcos0  A  1 
j^srosinflo  A  rsin0  =  rosin0o  As^  =  rsintf  J 
S' 

(rcos0  *  2r0cosffo  V*'  ^  rcos0)  A  1 
(rsin0  =  2rosin0o  Vy*  9*  rsin0)  J 

From  this,  the  Constraint  Strengthening  Rule  and  Rule  of 
Consequence  allow  us  to  derive 

□  (x'  J.  y*  A  x'  =  r  cos  8  A  —  r  sin  8) 

rcos9  =  r0costf0  A  1  f  rcos0  =  2rocos0o  A  1 
rsin  0  =  r0sin  0O  /  [  rsin  0  =2r0  sin  0O  / 

By  the  Rule  of  Consequence,  using  some  trigonometry  and 
the  previous  theorem  we  can  now  deduce 

□  (x'  J.  y'  A  x'  =  rcos0  A  /  =  rsin  8)  =» 

r  =  r0  A 0  =  0O  A  1  (  (r  =  2r0  A0  =  0O)  V  1 

r  >  0  A0<  0  <  2x  J  5  \  — <(r  >  0  AO<0<2?r)J 

We  now  use  the  Constraint  Strengthening  Rule  to  derive 

□  (x1  X  y1  A  x'  =  rcos0  A  i/'s  rsin  0  A 
r>OAO<0<  2tr)  => 

{ r  =  r0  A  0  =  0O}  S’  {r  =  2r0  A  0  =  0O} 

It  is  now  a  simple  matter  to  use  the  declare  Rule,  the  may 
alias  Rule,  and  finally  the  new  Rule  to  obtain  (7). 


6  Discussion 

We  have  introduced  the  idea  of  describing  types  and  alias¬ 
ing  in  terms  of  constraints  and  given  general  rules  for  rea¬ 
soning  about  constrained  execution.  Our  approach  involves 
embedding  the  usual  Hoare  partial  correctness  formalism  in 
temporal  logic.  One  reasons  about  static  properties  with 
constraints  and  about  dynamic  properties  with  pre-  and 
postconditions. 

Having  applied  our  method  to  a  simple  language,  we  now 
consider  some  of  the  problems  in  extending  it  to  more  com¬ 
plex  languages.  We  also  discuss  the  relation  of  our  approach 
to  previous  work. 

6.1  Types 

In  our  toy  language,  we  were  able  to  handle  a  type  dec¬ 
laration  simply  by  translating  it  to  a  constraint  about 
the  values  that  the  variable  can  assume.  This  does  not 
work  for  languages  that  make  more  extensive  use  of  type 
information — for  example,  by  performing  coercions  in  the 
event  of  a  type  mismatch;  nor  does  it  work  for  languages 
in  which  a  type  mismatch  in  an  assignment  generates  an 
indeterminate  result  rather  than  abortion.  (Our  semantics 
causes  abortion  if  executing  an  assignment  would  violate  a 
type  constraint.) 

Reasoning  about  these  more  complex  languages  requires 
adding  state  predicates  that  characterize  the  type  of  a  vari¬ 
able  and  modifying  our  Axiom  of  Assignment.  However, 
care  must  be  employed  when  reasoning  about  predicates 
like  type(x)  =  ‘integer  because  x  =  y,  which  means 
that  the  values  of  x  and  y  are  equal,  does  not  imply 
type(x)  *  type(y). 

If  a  type  mismatch  can  abort  execution,  reasoning  about 
type  correctness  requires  proving  total  correctness  proper¬ 
ties.  While  we  have  not  yet  considered  this  problem,  we 
feel  that  our  approach  should  be  ideal  for  proving  termi¬ 
nation  properties  because  it  is  based  upon  temporal  logic, 
and  temporal  logic  is  effective  for  proving  liveness  proper¬ 
ties  like  termination  [16]. 

6.2  Generalized  Assignments: 

Expressions  as  Targets 

In  the  Cartesian/polar  coordinate  example,  x  is  aliased  to 
rcos0.  Thus,  assigning  to  x  is  the  same  as  assigning  to 
rcos0.  The  obvious  next  step  is  to  try  writing  rcos0  on 
the  left-hand  side  of  an  assignment  statement,  even  if  there 
is  no  variable  aliased  to  this  expression.  For  arbitrary  ex¬ 
pressions  expi  and  exp-,  the  statement 

expi  :=  exp- 

causes  the  value  of  expt  after  execution  to  be  the  same  as 
the  value  of  exp-  before  execution.  To  reason  about  this 
form  of  generalized  assignment,  we  extend  1  to  be  a  rela¬ 
tion  on  expressions  rather  than  just  on  variable  names.  The 
temporal  formula  expi  J.  exp:  cow  means  that  assigning  to 


exp,  does  not  change  the  value  of  exp*,  and  vice-versa.  The 
axiom  for  generalized  assignment  is  the  same  as  the  Assign¬ 
ment  Axiom  given  above,  except  that  x  and  the  y,-  can  be 
arbitrary  expressions.  The  commutativity  and  substitution 
axioms  given  above  are  also  valid  for  these  more  general 
X  relations.  However,  additional  axioms  are  needed  for 
deriving  X  relations  between  expressions  from  X  relations 
between  their  components — axioms  such  as 

(exp,  X  expi)  A  (exp,  X  exp*)  =>  exp,  X  (expt  +  exp*) 
We  do  not  give  a  formal  semantics  for  this  here. 

6.3  Arrays  and  Pointers 

Our  approach  can  handle  arrays  by  regarding  assignment  to 
an  element  of  an  array  as  an  assignment  to  the  entire  array, 
as  described  in  [llj.  Array  assignment  cannot  be  handled 
using  our  generalized  assignment  statement,  where  an  ex¬ 
pression  like  A[i]  appears  on  the  left-hand  side,  because  this 
does  not  give  the  usual  semantics  for 

A[exp]  :=  exp'. 

Letting  the  subscripts  old  and  new  denote  values  be¬ 
fore  and  after  the  assignment,  the  semantics  of  general¬ 
ized  assignment  defines  the  above  statement  to  mean  that 
An»[expn(w]  s  exp‘M,  while  the  usual  meaning  of  array 
assignment  is  A^lexp^i]  —  exp’M.  This  difference  helps 
explain  why  the  ordinary  assignment  axiom  is  not  easily 
extended  to  arrays.  This  also  indicates  why  our  more  gen¬ 
eral  assignment  statement  is  not  easily  compiled,  since  it 
requires  computing  the  value  of  an  expression  in  a  (new) 
state  without  knowing  what  that  state  is. 

By  regarding  an  array  as  a  single  variable,  our  formalism 
can  handle  aliasing  relations  between  entire  arrays.  How¬ 
ever,  our  current  formalism  does  not  handle  simple  aliasing 
of  array  elements.  For  example,  if  x  is  not  aliased  to  any  ele¬ 
ment  of  the  array  A,  then  we  can  easily  prove  that  assigning 
a  value  to  A|l]  does  not  change  x’s  value  by  deducing 

□  x  X  A  =>  (x  =  7)  A\l]  :=  1  {x  =  7} 

However,  we  cannot  do  this  just  knowing  that  x  is  not 
aliased  to  .1(1],  because  our  rules  are  not  strong  enough 
to  prove 

□  x  X  .4(1]  =>  {x  =  7}  A\l\  :=  1  (x  =  7} 

The  required  generalization  must  replace  X  with  a  non- 
commutative  relation,  since  the  assertion  that  assigning  to 
A(tj  does  not  change  i  is  not  equivalent  to  the  assertion  that 
assigning  to  i  does  not  change  A[»j.  Moreover,  aliasing  re¬ 
lations  are  no  longer  static,  since  whether  A[«|  and  x  are 
aliased  may  depend  upon  the  value  of  i.  Being  dynamic, 
aliasing  relations  like  X  have  to  appear  in  pre-  and  post¬ 
conditions.  which  is  prohibited  by  the  current  formalism. 

Similar  extensions  are  needed  for  reasoning  about  alias¬ 
ing  in  programs  that  use  pointers.  Moreover,  in  a  language 


with  pointers,  type  relations  might  also  be  dynamic— for 
example,  if  a  pointer  can  point  to  variables  of  type  real 
and  of  type  [0, 2  *  it).  In  this  case,  type  relations  would 
have  to  appear  in  pre-  and  postconditions. 

These  extensions  will  be  described  in  a  future  paper. 

6.4  Procedures 

The  most  general  form  of  parameter  passing  is  call  by  name, 
since  it  can  be  used  to  simulate  call  by  reference  and  call 
by  value-result.  With  call  by  name,  a  formal  parameter  is 
essentially  aliased  to  the  corresponding  argument.  Thus, 
our  approach  can  be  used  for  reasoning  about  procedures. 

TYaditionally,  programming  languages  with  procedures 
do  not  allow  an  arbitrary  expression  as  the  argument  cor¬ 
responding  to  a  formal  parameter  that  appears  on  the  left- 
hand  side  of  an  assignment,  since  assignment  to  an  expres¬ 
sion  is  not  defined  by  these  languages.  We  have  defined 
what  it  means  to  assign  a  value  to  a  variable  that  is  aliased 
to  an  expression,  so  there  is  no  semantic  reason  for  this 
prohibition.  However,  some  restriction  is  needed  to  ensure 
that  the  language  can  be  compiled. 

6.5  Related  Work 

Previous  work  on  aliasing,  [1,3, 4, 5, 6, 7, 9],  has  been  moti¬ 
vated  by  shared  storage  among  arguments  of  a  procedure 
call.  We  are  aware  of  no  work  that  can  handle  the  rich 
aliasing  structures  that  concern  us.  However,  program¬ 
ming  languages  where  computations  are  partially  or  com¬ 
pletely  specified  in  terms  of  constraints  have  been  investi- 
gated  [2,19,20,21,22]. 

In  most  previous  work  on  aliasing,  the  program  state 
consists  of  a  mapping  from  variable  names  to  a  space  of 
(abstract)  locations  plus  a  map  from  locations  to  values. 
We  feel  that  if  the  language  itself  has  no  pointers,  then 
the  semantics  should  not  be  given  in  terms  of  pointers, 
even  if  the  values  of  these  pointers  are  abstract  locations 
instead  of  real  memory  addresses.  Moreover,  the  existence 
of  semantic  pointers  unnecessarily  complicates  reasoning 
about  programs.  Also,  approaches  based  on  locations  are 
rarely  fully  abstract  [3j.  Finally,  and  most  importantly,  the 
use  of  locations  does  not  support  reasoning  about  the  more 
general  form  of  aliasing  that  is  not  based  on  shared  storage. 

Our  work  resembles  Reynolds’  [17]  handling  of  call  by 
name  in  many  ways.  Reynolds  defines  a  formal  system, 
called  Specification  Logic,  that  contains  a  relation  #  very 
similar  to  X  and  an  assignment  rule  much  like  ours.  The 
effects  of  aliasing  are  described  in  terms  of  interference , 
which  can  be  seen  as  the  dual  of  our  viewing  aliasing  in 
terms  of  invariants.  (See  [14]  for  a  discussion  of  the  relation 
between  interference  and  invariance.) 

The  meaning  of  a  formula  in  Specification  Logic  is  based 
on  an  environment  in  addition  to  a  state.  The  environment 
is  a  mapping  from  variable  names  to  a  space  of  locations 
and  brings  with  it  the  difficulties  mentioned  above.  In  ad¬ 
dition,  in  Specification  Logic,  assertions  about  the  environ¬ 
ment  are  made  using  a  completely  new  logic,  distinct  from 


lie  one  used  to  reason  about  the  state.  In  our  approach, 
U  reasoning  is  done  in  a  single  logical  system — temporal 
>gic.  Assertions  about  the  state  are  expressed  by  tempo- 
ally  trivial  formulas — formulas  containing  no  temporal  op- 
rators.  We  do  not  need  the  concept  of  an  environment,  us* 
ig  instead  temporal  assertions  about  the  state.  Of  course, 
pecification  Logic  handles  forms  of  aliasing  not  considered 
i  this  paper.  We  are  currently  extending  our  temporal 
>gic  approach  to  cover  the  full  range  of  language  features 
andled  by  Specification  Logic. 

Our  approach  can  be  viewed  as  a  generalization  of  one 
roposed  by  Brooks  13],  and  we  were  somewhat  influenced 
y  his  work.  We  handle  a  much  more  general  form  of  alias- 
ig,  but,  if  we  restricted  ourselves  to  aliasing  relations  that 
re  simple  equalities  between  variables,  then  proofs  in  our 
ystem  and  in  Brooks’  would  be  quite  similar.  To  extend 
Irooks’  work  to  handle  our  more  general  form  of  aliasing, 

[  appears  that  a  new  deductive  method  would  have  to  be 
dded;  we  avoided  this  by  embedding  our  proof  system  in 
emporal  logic. 
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Lppendix 

?he  Formal  Semantics 

ul  The  Language 

>'e  now  give  a  formal  semantics  for  our  toy  language  con- 
lining  skip,  assignment,  concatenation,  and  while,  plus 
le  three  statements  new,  declare,  and  may  alias  intro- 
iiced  to  model  the  var  statement.  The  class  of  expres- 
ons  and  variable  types  is  not  specified.  We  assume  only 
tat  expressions  are  built  from  some  set  Var  of  variable 
ames.  that  variables  assume  values  in  some  set  Val,  and 
lat  expressions  are  built  from  operators  on  those  values, 
owever,  in  the  statement 

declare  C  in  5 

'  can  involve  X  in  addition  to  Boolean  expressions. 
Finally,  we  require  the  value  of  an  expression  to  be  de- 
ned  for  any  values  of  its  component  variables.  Thus,  the 
impression  z  +  10  must  be  assigned  a  value,  even  when 
s  true.  This  can  be  done  by  including  a  special  value 
ndefined  in  Val ;  the  precise  details  for  doing  this  are  ir- 
elevant. 

1.2  Temporal  Logic 

i  state  is  defined  to  be  a  mapping  from  Var  to  Val,  so  a 
tate  s  assigns  a  value  s(x)  to  every  variable  name  z  g  Var. 
,et  S  denote  the  set  of  states.  A  state  a  is  extended  to  a 
lapping  from  ordinary  (nontemporal)  expressions  to  values 
i  the  obvious  way — for  example,  a(z  +  y)  is  defined  to 
qua!  s(x)  +  s(y).  Let  a  N  exp  denote  the  assertion  that 
(ezp)  =  true,  (a  )=  z  >  10  is  false  if  a(z)  has  a  nonnumeric 
alue.) 

An  action  is  defined  to  be  an  element  of  VarU{r},  where 
is  a  symbol  not  in  Var.  For  z  g  Var,  action  z  represents 
n  assignment  to  z.  Action  r  represents  an  assignment  to  a 
ariable  declared  in  some  new  statement  inside  the  current 
tatement;  thus  r,  models  a  variable  that  is  “invisible"’  in 
he  current  context. 

A  behavior  is  defined  to  be  a  sequence  a  of  the  form 

a0  —  •••  a„  (8) 

.  here  the  a,  are  states  and  the  z,-  are  actions.  This  behavior 
enotes  an  execution  starting  in  state  So  and  terminating 
I  state  a*,  where  the  «th  action  changes  the  state  from 
i_i  to  Si.  Since  partial  correctness  does  not  distinguish 
.etween  aborting  and  infinite  looping,  we  consider  only  fi- 
ite  (terminating)  behaviors,  although  our  definitions  are 
asily  extended  to  include  infinite  (nonterminating)  ones. 
Ve  allow  the  case  n  =  0,  where  »0  is  the  behavior  starting 
a  state  a0  that  performs  no  actions. 

In  the  temporal  logic  of  (13),  a  formula  is  composed  of 
tate  predicates,  action  predicates,  and  temporal  operators, 
"he  set  of  Boolean  expressions  is  taken  to  be  our  state 
iredirates.  Action  predicates  are  those  of  the  form  a(x), 


together  with  the  action  predicate  halt .  A  Boolean  expres¬ 
sion  is  true  of  a  behavior  if  it  is  true  of  the  first  state  in  the 
behavior.  An  action  predicate  o(z)  is  true  if  z  is  the  first 
action  in  the  behavior;  action  predicate  halt  is  true  only 
if  there  is  no  next  action.  The  semantics  of  this  temporal 
logic  assigns  a  truth  value  to  o  N  F  tor  every  behavior  a 
and  every  formula  F.  We  write  )=  F  to  denote  that  a  N  F 
is  true  for  all  behaviors  a. 

We  will  define  a  behavioral  semantics  for  our  language 
where  X[5J  is  a  set  of  behaviors  representing  all  possible 
terminating  executions  of  5.  Semantic  validity  of  a  tempo¬ 
ral  logic  formula  F  for  a  program  S  is  defined  by 

Ns  F  d=f  Vo  g  A<[S] :  a  (=  F 

To  define  the  temporal  operator  X,  we  first  define  the 
operator  J  by  letting  cr^xJy  mean  that  if  the  first  action 
of  a  is  an  assignment  to  z,  then  that  assignment  does  not 
change  the  value  of  y.  In  other  words,  letting  a  be  the 
sequence  of  (8),  we  have 

a  N  z  Jy  =  (z  ^  z,)  =>  (a0(y)  =  a,(y)) 

In  the  temporal  logic  of  [13], 

*  Jy  -  Vn  -  (y  = »/ )  =-  (a(x)  <  y  =  n) 

We  define  z  X  y  to  be  (z  Jy)  A  (y  Jz).  Note  that  a  N  x  X  y 
is  true  if  a  is  a  sequence  with  no  actions. 

The  formulas  deduced  by  our  method  for  reasoning  about 
programs  are  of  the  form  OC  =>  {P}S  {(?},  where  C  is 
a  temporal  logic  formula.  However,  {P}  S  (Q)  is  not  a 
temporal  logic  formula  because  it  refers  to  the  statement 
S — a  concept  with  no  counterpart  in  the  temporal  logic. 
To  make  semantic  sense  out  of  this  formula,  first  define 
(P)  — >  {Q}  to  be  true  for  the  behavior  (8)  if  and  only  if 
»c  (=  P  »  a,  N  Q  This  is  defined  in  terms  of  temporal 
logic  operators  by 

{P}  -  (Q)  =  p  =>  a{hatt~Q) 

A  program  5  satisfies  □  C  »  {F}  S  {Q}  if  and  onlv  if 

Ns  DC=>{P)  -  {Q}. 

A. 3  The  Behavioral  Semantics 

For  any  statement  5  in  our  language,  we  define  M|5I  to 
be  a  set  of  behaviors.  The  definition  is  by  induction  on  the 
structure  of  5. 

skip  >4  [skip]  d=  (s0  :  s0  g  S} 

The  skip  statement  generates  no  actions. 

assignment  M[z  :=  exp ]  ='  {a  t  :  <(x)  =  a(exp)} 

An  assignment  generates  a  single  action  that  sets  the 
value  of  the  left-hand  side  to  the  original  value  of  the 
right-hand  side.  Note  that  M[5]  contains  behaviors 
that  make  arbitrary  changes  to  other  variables,  since 
any  such  change  could  be  caused  by  an  appropriate 
aliasing. 


tenation  X(5t;  Sj]  is  defined  to  equal 

{«o  ...  : 

•o  -»•  -a.  ».6Xls,i 

aad,,  ill  s.^  6X15,1} 

Note  that  we  are  including  only  finite  (terminating) 
behaviors. 

We  define  X  (while  B  do  5]  inductively  by 

X|whileo  B  do  S]  =  {e0  €  S  :  t0(B)  =  false) 
M  [while,*,  B  do  5]  = 

(e0  ...  X(5;  while,  B  do  SJ : 

•o  (B)  =  true} 

X  [while  B  do  5]  =  USo  X  [while.  B  do  S( 

Intuitively,  X  [while,- . . .  J  contains  the  behaviors  in 
which  the  body  of  the  while  statement  is  executed 
exactly  i  times. 

re  X [declare  C  in  SJ  =  {a  6  X[S]  :  a  \=  DC} 
The  declare  acts  as  a  ‘‘filter”  to  eliminate  any  be¬ 
haviors  of  5  in  which  C  does  not  always  hold. 

If  a  is  the  sequence  (8),  let  <r[x,/y,, . . .  ,*»/y»]  de¬ 
note  the  sequence 


where 


*,-(«)  if  Vj  :  v  x j  and  v  jt  t/j 


*'<(«>)  =  |  s0(xy)  if  u  Xj 

(9) 

[  «o(yy)  if  u  Vi 

x>  -  J  *.  if  Vj  :  xj ;  *  yj 

(10) 

[  r  otherwise 

Then  a  €  XJnew  xt, . . . ,  x„  in  5]  if  and  only  if 
there  exist  variable  names  yt,  ...  ,  y*  not  free  in 
5  and  o'  e  X[S[y,/x1,...,yB/*B]l  such  that  <r  * 
<*Wyi . 

This  formal  definition  captures  the  intuitive  notion 
that  to  execute  the  new  statement,  one  first  exe¬ 
cutes  its  body  with  new  variables  y,  substituted  for 
the  Zi.  The  resulting  execution  is  then  modified  by 
hiding  all  references  to  the  variables  y, — replacing 
assignments  to  the  y,-  by  r  actions  and  letting  y< 
refer  once  more  to  its  external  declaration — and  re¬ 
quiring  that  the  externally  declared  values  of  the  z,- 
remain  unchanged. 

alias  X[x  may  alias  x, , ,  x„  in  5]  is  defined  to 
equal 

tyn 

{<r  €  X[5|  :  Vy  :  (Vi :  y  x.)  re  a  ^  D(x  X  y)} 

This  is  the  formal  definition  of  our  intuitive  idea  that 
the  may  alias  is  equivalent  to  a  declaration  of  an 
an  infinite  number  of  X  relations. 


A.4  Soundness  and  Completeness 

In  the  main  body  of  this  paper,  we  gave  a  set  of  rules  for 
deriving  formulas  of  the  form  □  C  re  {P}  S  {Q}  Having 
defined  the  set  of  behaviors  X[S],  we  have  given  a  semantic 
meaning  to  these  formulas,  namely: 

X[QC  re  (P}S{Q}J  (=5  acre-  {P}  -  {Q} 

We  can  now  discuss  the  soundness  and  completeness  of  our 
system. 

Soundness  means  that  for  any  formula  F  derived  by  our 
system,  M[F(  equals  true.  The  proof  of  this  involves  check¬ 
ing  the  validity  of  all  our  axioms  and  proof  rules.  This 
involves  a  straightforward  formalization  of  the  informal  ar¬ 
guments  given  in  section  4. 

Completeness  means  that  every  semantically  correct  for¬ 
mula  is  derivable  using  our  rules.  Since  completeness  is 
impossible,  one  usually  proves  relative  completeness  in  the 
sense  of  Cook,  which,  as  explained  in  [1],  means  that  the 
system  is  complete  if  we  assume  that: 

Cl.  All  valid  state  predicates  are  given. 

C2.  The  set  of  state  predicates  is  sufficiently  expressive, 
meaning  that  for  any  state  predicate  P  and  statement 
5,  posts(P),  the  strongest  postcondition  of  P  with  re¬ 
spect  to  5,  is  a  state  predicate. 

These  assumptions  are  not  enough  to  guarantee  com¬ 
pleteness  in  our  system.  In  ordinary  Hoare  logic,  one  as¬ 
sumes  the  ability  to  reason  about  state  predicates.  Since 
formulas  in  our  logic  contain  temporal  operators,  like  □ 
and  X,  we  need  to  reason  about  temporal  logic  formulas. 
We  therefore  assume  that* 

Cl*.  All  valid  temporal  logic  formulas  constructed  from  the 
state  predicates  are  given. 

where  a  valid  temporal  logic  formula  is  one  that  is  true 
for  any  behavior.  Thus,  just  as  assumption  Cl  for  or¬ 
dinary  Hoare  Logic  contains  only  information  about  the 
state  space — not  information  about  the  program — so  Cl' 
gives  information  about  state  functions  and  temporal 
operators — not  about  the  program.  Since  state  predicates 
are  temporal  formulas,  Cl'  subsumes  Cl. 

In  addition  to  strengthening  Cl,  we  must  also  strengthen 
C2.  To  see  why,  suppose  our  set  of  state  predicates  did  not 
contain  the  predicate  true,  but  required  that  we  use  the 
semantically  equivalent  predicate  z  =  x.  Our  Assignment 
Axiom  does  not  allow  us  to  deduce  (x  =  x}  y  :=  1  (x  =  x}; 
we  can  only  deduce  it  under  the  irrelevant  hypothesis 
□  (y  X  x).  In  general,  we  need  to  assume  that  if  a  state 
predicate  does  not  depend  upon  the  value  of  a  variable  x, 
then  we  can  write  that  predicate  as  an  expression  that  does 
not  involve  x.  We  therefore  require  the  following  additional 
expressiveness  condition: 

sActua!ly,  this  assumption  is  stronger  tban  necessary.  sin.-e  wo 
are  concerned  onlv  with  temporal  logic  formulas  of  t1  form 
QC  =»  {P)S(Q} 


r  any  expression  exp,  mathematical  function  /,  and 
riables  y,, . . . ,  y„:  if  the  relation  exp  =  /(y,, . . . ,  y„) 
valid,  then  /{yi,  • . . ,  y«)  is  an  expression. 

ng  made  these  extra  assumptions,  we  now  con- 
jmpleteness.  Completeness  for  ordinary  Hoare  logic 
that  every  valid  formula  is  provable.  In  our  system, 
xe  formulas  of  the  form  OC  =>  {P}  5 {<?},  where 
ihe  form  C'A(x  X  y,)A...A(x  X  y„)  and  C*  is  an  or- 
(nontemporal)  expression.  Completeness  therefore 
that  every  valid  formula  erf  this  form  is  provable, 
proof  is  by  induction  on  the  structure  of  5.  If  5  is 
statement,  then  □  C  =>  {P}  S  {<?}  is  semantically 
lent  to  (C'  a  P)  =>  Q.  By  assumption  Cl',  this  is 
le,  and  we  can  use  it,  the  ordinary  axiom  for  skip 
ldp{P}),  the  Rule  of  Consequence,  and  the  Con- 
Strengthening  Rule  to  deduce  □  C  =>  {P}S[Q}. 
etails  are  left  to  the  reader.) 
t,  let  S  be  the  assignment  statement  x  :=  exp.  A 
uence  of  Cl'  is  a  complete  system  for  deriving  X 
ns.  Thus,  we  can  assume  that  C  includes  all  relations 
r,  that  are  derivable  from  it.  It  is  easy  to  see  that 
>  {P)  S  {<?}  is  semantically  equivalent  to,  and,  by 
instraint  Strengthening  Rule,  derivable  from 

X  y,  A  ...  A  x,  i.  y,)  =»  {PaC}  5  {Qv->C"} 

d  therefore  restrict  consideration  to  the  case  in  which 
lists  only  of  the  conjunction  of  the  constraints  x,-  X  y,. 
e{P)  5  {<?}  is  semantically  equivalent  to  posts(P)  => 
the  Rule  of  Consequence  and  C2,  we  can  let  Q  = 

n 

Q  =  Q(t,  Si,...,  xm),  where  the  x,  are  different  from 
C2a,  we  can  assume  that  the  value  of  Q  depends 
tach  of  the  iy.  Since  Q  =  poats(P),  this  means  that 
is  a  behavior  «  t  in  A4  [5"J  such  that  a  P  , 
Q  for  some  state  ('  that  differs  from  <  only  in  the 
of  2j.  However,  since  the  semantics  of  S  does  not 
ain  the  ending  values  of  any  variable  other  than  x, 

•  t*  is  in  X[S|.  Therefore,  if  x  X  Xy  were  not  one 
constraints  in  C,  then  DC  =>  would  be 

I.  Hence,  the  constraint  C  contains  all  the  X  relations 
1  to  apply  our  Assignment  Axiom,  and  completeness 
s  bv  the  same  argument  as  in  v  ie  ordinary  Hoare 
(11- 

proof  for  the  declare  is  immediate,  since  if  5  is  the 
tent 

declare  C  in  S' 

OC  =>  {/>}5{Q}  is  semantically  equivalent  to 
\  C)  =»  {P}  S'  {<?}.  Similarly,  if  5  is  the  statement 

x  may  alias  x( , . . .  x.  in  5* 

suit  follows  from  the  fact  that  □  C  is 

tically  equivalent  to  oCaC  =>  {P}  S'  {<?},  where 
(x  X  y,)  A  . . .  A  (x  X  ym)  and  the  y,  are  all  the 
le  names  other  than  the  Xy  that  appear  in  P,  C,  and 


To  finish  the  completeness  proof,  we  must  show  that  for 
every  compound  statement  S,  we  can  prove  every  valid 
formula  OC  =>  { P}S  {(?}  under  the  assumption  that  we 
can  prove  every  such  formula  for  the  components  of  S. 
This  involves  a  separate  proof  for  every  type  of  compound 
statement.  The  proofs  for  concatenation,  while,  and  new 
are  similar  to  the  ones  for  the  ordinary  Hoare  logic  given 
in  [1].  The  only  difference  in  the  proofs  arises  because  of  the 
uUC  The  proofs  in  [1]  rely  on  the  fact  that  {P}  S  {Q} 
is  valid  iff  poals(P)  =>  Q.  The  formula  OC  =>  {P}5{<?} 
is  valid  iff  {P}  declare  C  in  S  {Q}  is  valid,  by  the  seman¬ 
tic  equivalence  mentioned  above.  This,  in  turn,  is  valid  iff 
P°4*d««Ure  c  in  s(^)  ®  expressable,  and  implies  Q.  How¬ 
ever,  expressability  follows  from  our  assumptions  C2  and 
C2a.  With  this  observation,  the  completeness  proofs  of  [1] 
are  now  easily  extended  to  our  more  general  class  of  asser¬ 
tion. 


